BruceTTTT

Is there any way to force FireDAC to use the new OLE DB Driver (not the older Provider) in the msoledbsql file? Discussed here: https://docs.microsoft.com/en-us/sql/connect/oledb/oledb-driver-for-sql-server?view=sql-server-ver15 https://docs.microsoft.com/en-us/sql/connect/odbc/windows/microsoft-odbc-driver-for-sql-server-on-windows?view=sql-server-2017 https://support.microsoft.com/en-us/office/connect-access-to-sql-server-050d88f3-b2d6-4e76-b6f9-f3c556f139ea The native client drivers are deprecated, and I can use the related ODBC 17 driver, but it's slower. ADO (dbGo) with the new OLE DB driver is the fastest, but I'd like to switch to FireDAC and I'm forced to use the ODBC 17 driver if I do that because of the incompatibilities of the native SQL driver (that FireDAC uses) and different SQL versions.

I tested this many times as well (see the above QC ticket), ODBC was slower loading. And there's also the configuration of the ODBC driver on each client that you must do sometimes. The main problem I have with the Native Client is that it's keyed to the version of SQL Server. We have multiple versions on our servers, and there's no on Native Client that can handle them all. The nice thing about ADO + OLEDB is that this is not an issue. When using the newest OLEDB driver from Microsoft and ADO, all of these issues are resolved. It's fast, one driver works on everything. But of course, it doesn't have all of FireDAC's new stuff. I don't know why this is such a big deal for Emb. Just implement this driver. SQL Server is everywhere, why wouldn't you want to implement the best solution?

I was starting to like FireDAC and was beginning recoding all my apps from ADO to FireDAC, then this happened. I hate ODBC, so I'm still sticking with ADO.

Emb decided not to address it and closed the QualityCentral request I posted (sorry, don't remember the number, but you can look it up). They said that FireDAC for SQL Server "uses ODBC" and left it at that. Very disappointing to me.

The problem with Code Templates though, is that they require a space at the end. It may sound trivial but I want ";;" to immediately convert to ":=" without having to type ";;<space>". GExperts is the only thing I've found that will do it. Regardless, I use GExperts for a lot of other things, it's just that this is my favorite feature.

This single feature is why I can't live without GExperts. (AutoHotKey is similar, but responds slower.) I started autocorrecting ;; to :=<space> with one of the earlier versions of Delphi and can't live without it now as a time saver. Hitting the Shift key to get : is annoying.

If you're willing to install AutoHotKey, these two scripts can substitute for the Parnassus stack bookmarks: #IfWinActive ahk_class TAppBuilder ^n:: Send ^k^g return #IfWinActive ahk_class TAppBuilder Escape:: Send ^q^g return I'm using Ctrl-n to drop a marker, and Esc will collect the last marker. Works well for me.

For what it's worth, we use floating point numbers a lot here in our scientific work, and the accuracy is critical. Add in unbiased rounding rules (i.e. banker's rounding), multiplication, division, and averaging first, and it's even more complicated. Between Delphi, C#, and the shared SQL Server backend, I got so frustrated with rounding variations, storage of numbers (e.g. 1.025 sometimes stored as 1.025000001 or 1.0249999999) that I ended up writing my own rounding routines using string conversions, custom digit management, etc.

Ditto. At least they could tell us when and if it's expected so I could stop checking.

Thanks for this info. I've been wrestling with this issue for a while. 10.x had the ability to turn LSP off and use the legacy version, which often fixed the Ctrl-click issues. Not being able to Ctrl-click an identifier drives me nuts and I'm always looking for a good resolution. Newly opened projects seem to have less of an issue, but it is definitely the longer units for more complex projects that fail.

But the best feature for me is to be able to quickly drop a stack-based bookmark, move anywhere, then simply hit Esc to go back where you were.

I concur. Never been able to produce a web app so quickly. www.unigui.com

Thanks for this too, much better. Now if I can just get the older "Open Recent" back, I hate the two columns and the layout.

My experience too. But putting the cursor on a new property (e.g. AutoDropDownWidth in TComboBox) still fails since it loads 10.4.2. I can go to the DocWiki, but that takes a bit to find what you're looking for. But there's not that much new in 11 so I guess it's not too big of a deal.

Is Help working for anyone else? It's not for me. Sometimes I get the 10.4.2 help, other times nothing (when pressing F1).

Wonderful! This is loaded and working. Many thanks.

Appreciate the work too. I've been trying to modify the source myself to get it compiled on Alexandria, and making some progress, but I've hid a brick wall in the GX_OtaUtils unit. Telling me there are function declarations that don't agree with each other and I cannot find where the multiple declarations are (e.g. GxOtaGetEditorLine) for the life of me. I just can't use Delphi without GExperts. It's too painful when I've been used to it for years. Until GExperts is working, D11 will have to wait...

Is there a full white paper of all changes, bug fixes, additions, etc. yet? I can't seem to find a detailed list.

Same thing is true for the Parnassus IDE add-ons as well evidently.

For what it's worth, if you "delete" rows by reducing the RowCount, I'd recommend clearing the cell contents first. I found many situations where I'd reduce the RowCount, then increase it later and the cell contents were still there. This may have been fixed in later versions of Delphi as I've not checked it in a while.

My experience exactly as well. Can't figure out a pattern either, gets annoying at times. I seem to have the problem more with 10.4.2 than 10.4.1 (but 10.4.2 fixed a lot of other problems).

My experience is similar too. Does not work with TMainMenu, and it has painting issues (e.g. add a TSpeedButton to the TTitleBarPanel and toggle the Flat property). The ShowCaption property doesn't seem to work either.

Is the ZeosLib for FireDAC? I.e. is it installed as ODBC so FireDAC can see it? Otherwise the the msoledbsql OLE DB driver works fine with dbGo... Bruce

There are no "problems" with the native client except for compatibility with versions of SQL Server. Depending on which version of the server you are running (including with Express), you have to pick the correct native client. There are times my software has had to support 5 different versions of the server (2008 all the way through 2019), and supporting a different driver each time gets annoying fast. So far with my testing, the msoledbsql ("Driver", not "Provider") and the related ODBC 17 driver just released by Microsoft are compatible with all versions of SQL Server. This is really helpful when the app or client needs to access different versions. And as mentioned above, ODBC 17 is slower. Bottom line for me right now, dbGo using this new driver is still the fastest and most agile solution. Supporting ODBC 17 as a choice is great for options, but in all my testing, there is still overhead vs. using the OLE DB "Driver" directly. https://docs.microsoft.com/en-us/sql/connect/oledb/oledb-driver-for-sql-server?view=sql-server-2017 In their words: ... SQL Server Native Client OLE DB provider (SQLNCLI) remains deprecated and it is not recommended to use either for new development work.

I've done some basic testing and for the newest drivers (e.g. ODBC 17 and the OLE DB (msoledbsql) "Driver" (not "Provider")), the speeds in decreasing order (fastest at the top): OLE DB (msoledbsql) SQL Server Native Client ODBC 17 The native client drivers *are* deprecated by Microsoft, replaced by the OLE DB driver and ODBC 17 ones listed above. Since FireDAC cannot use the OLE DB driver, I'm forced to pick either the ODBC 17 or use the native client. This is frustrating because the native client has issues with SQL 2019, and the ODBC driver (while it can connect to any version of database) is slower.