Search the Community

Delphi Version: 12.2 Athens Database: SQL Server Driver: FireDAC MSSQL Query Type: Live TFDQuery, UpdateOptions.UpdateMode := upWhereAll Context: Migrating from BDE with many legacy TFloatField components Problem Summary When FireDAC’s FormatOptions.MapRules are configured to map BCD and FMTBCD fields to Double, FireDAC mishandles actual FLOAT database fields during auto-generated UPDATE statements. Specifically, it generates a WHERE clause where the FLOAT field is incorrectly bound as decimal(22,20) — causing loss of precision and failed row matching. Reproduction Conditions SQL Server table contains: pop_density FLOAT NULL Delphi TFDQuery includes: A persistent TFloatField bound to this column. UpdateOptions.UpdateMode := upWhereAll FormatOptions.MapRules contains: MapRules.Add(dtBCD, dtDouble); MapRules.Add(dtFmtBCD, dtDouble); (This is necessary to preserve compatibility with hundreds of legacy TFloatField components from a BDE application.) The float value in the database is something like 1.23456789123E-10. FireDAC generates the following: exec sp_executesql N' UPDATE dbo.unit SET ... WHERE ... AND pop_density = @P5', N'@P5 decimal(22,20)', 123456789123 The float value is bound as a decimal, stripping both the decimal point and exponent — resulting in no match. Observations This does not occur in a small test app unless MapRules are set. OldValue of the field is correct and contains the scientific notation. Field class is TFloatField. Problem only arises when MapRules include rules to map to dtDouble. Workarounds Use UpdateOptions.UpdateMode := upWhereChanged to avoid the float field being used in the WHERE clause. This breaks the "another user changed the row" functionality. Avoid setting MapRules globally. Would require upgrading every persistent TFloatField. Manually override update SQL via TFDUpdateSQL. High effort. Legacy applications contain a large number of live queries using persistent TFields. Why This Matters This is a blocking issue for anyone migrating a BDE-based application where all numeric fields were defined as TFloatField (common BDE behavior). Using FireDAC’s MapRules to redirect BCD types to Double is a clean workaround — but this side effect breaks updates on real FLOAT columns. Problem has also been observed on database fields defined as NUMERIC. Conclusion FireDAC's parameter binding logic incorrectly applies decimal formatting to native SQL Server FLOAT fields and sometimes NUMERIC fields when MapRules redirect BCD/FMTBCD to Double — even if the persistent field is explicitly a TFloatField. Would appreciate any insights or confirmation from others facing this during BDE → FireDAC migration. EDIT: The issue only seems to occur when the value in the float field uses a negative exponent greater than 6. For example, the problem occurs when the float = 1E-07, but not 1E-06. I have attached a small test program that demonstrates the problem, with a SQL file to build the test table and add a couple of data rows. If I modify any value in the row containing 1E-07 in the pop_density column, I get the error: [FireDAC][DApt]-400. Update command updated [0] instead of [1] record. test.zip

Hi all, I recently migrated from D7 BDE (SqlServer) to D11 FireDac. All is working just fine, but the performance are getting worse. Have you got any advice about the better set up? Most of my query are read only select, aming to popolate DbGrid or to save data to other kind of structure. Thanks in advance

Hello everyone, I am in the process of converting an old project from Bde to Firedac. Basically it's relatively easy, but now I'm at a point where I'm a bit desperate. With the Bde, TDatabase and TTable/TQuery components, I had set up a central connection in my main program and opened all the necessary TTable tables. Now DLLs of the program (dynamically loaded with LoadLibrary) could call a function in the central location (export method) and, for example, fetch a TTable object corresponding to a specific table. Regardless of whether the design is good or bad, it worked without any problems. We used "ShareMem" in the main application and all the DLLs. I then had access to the tables of the main program in the DLL and could, for example, call FindKey to jump to a specific position in the DB. With Firedac I left everything as it was, only instead of TDatabase I used TFDConnection and accordingly TFDTable etc. The code is definitely correct, I can connect and display the data in the Dbgrid. FindKey from the main program also works. Nevertheless, I always get false with FindKey from the DLL after I have fetched the TFDTable. Does anyone have any experience with this? Could it be that the connection does not arrive correctly in the DLL when I get the TFDTable object? On the other hand, something like fdtable.fieldbyname(...) works without problems from the DLL. So I don't understand why FindKey doesn't work. It is also the same TFDTable object that I get back from my main application, indexfieldnames is also correct, table and connection are open and everything. Nevertheless it does not work. Would be grateful for a hint, especially since it works with TTable. I hope I was able to explain the problem. FindKey was just an example, I´m not sure, if other methods called in the dll work properly either. The Idea behind this concept is that we have a central place and all DLLs have access to the main tables and can change the cursor position of the table or can be updated when another DLL changes the position of a table, because they all use the same tables from the main application. Is there a better concept for this in FireDac with DLLs? Or do I need to create methods in my main application for Table updates or methods like "FindKey" which can be called from the DLLs? That would be a huge refactoring and I want to avoid this! Thanks a lot!

A long shot and completely related to my other post about d11-update-1-firedac-odbc-to-sage-returning-wrong-data. If I could make the original connection open then all would be good. Basically when I try and connect to the DB in my old app, I get a generic error. I have turned on ODBC logging, which didn't help. Knowing someone else has it working would mean it was worth trying to get to the bottom of that problem, rather than trying to track down a potential bug in D11. TIA JAC.

Hello, I recently installed the BDE components for Delphi 10.4.2 to test an abswer I was writing on StackOverflow. Then, a couple of days ago, a failed Windows bios update meant that I had to re-install Windows (and Delphi) from scratch. I couldn't immediately find the BDEInst.Exe I'd used to install BDE support (TTable. TQuery, etc) and googling around only led me to a couple of links to installing BDE support from the XE7 era and there is no BDE Installer for 10.4.2 in the "My Registered Products" section of the Idera website. Fortunately, I found the BDEInst.Exe I needed in the Downloads section of my profile under C:\Windows.Old. But, and I realise this might seem a slightly strange question, could somebody "remind" me please where I might have downloaded it from? TIA, Martyn

I am sorry to ask about the BDE in 2020, but we are trying to move a client from Windows7 to Windows10 and then eventually from the BDE to FireDAC I installed BDE v5.01 onto my machine using the installer ( 30868_bde_installer_for_rad_studio_delphi_c_builder_10.3_rio ) and apparently in order to give the client the ability to insall the BDE I must find BDE_ENT.msi on my machine ( in %programdata% ) and then give them that file to install. However, I cannot find BDE_ENT.msi anywhere on my system. I have even gone into %programdata% and manually searched for it and it is nowhere to be found. So, I guess my questions are: Do Embarcadero still sell or make available for download or to purchase the Enterprise version for clients ( not developers ) with a proper installer ? Can a proper installer be obtained from anywhere ? If the customer already has a licensed version of the BDE Enterprise (v4) are they allowed to get an updated installer ? Will this work on Window 10 (v4 or the latest version) ? What is the latest version of the client side of the BDE ? Sorry for all of these questions, but like I said earlier I am trying to move a client from Windows7 to Windows10 and then eventually from the BDE to FireDAC. So eventually they will be on FireDAC, but for now we need to get the BDE working.