BruceTTTT

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.

On 2/7/2022 at 9:56 AM, dummzeuch said:

If that's the only reason to install GExperts, you could get the same functionality with a Live Template (built in feature of the IDE) similar to this one:

convert typo ";=" to ":="

This will convert a common typo where you type ";=" but really meant ":=" to what you meant.

TEMPLATE FILE NAME: semicolon-equals-typo.xml

<?xml version="1.0" encoding="utf-8" ?>
<codetemplate xmlns="http://schemas.borland.com/Delphi/2005/codetemplates" version="1.0.0">
  <template name=";=" invoke="auto">
    <description>
      convert typo ;= to :=
    </description>
    <author>
      twm
    </author>
    <code language="Delphi" delimiter="|">
      <![CDATA[:= |end|]]>
    </code>
  </template>
</codetemplate>

 

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.

On 1/19/2022 at 9:10 AM, corneliusdavid said:

This is a great feature--I've used it both for proof-reading and for simple keyboard macro expansion (before Live Templates).

 

Using GExpert's Code Proofreader or Delphi's Live Templates, you can either auto-correct your most common misspellings or set up small keyboard macros to do the typing for you. For example, instead of typing "length" you could type "lg" and it would be expanded to "length" for you.  I misspell "string" a lot and so set up "sg" to type it out for me.

 

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.

On 11/12/2021 at 4:57 AM, Tom F said:

I just want my Bookmarks.  And I'm tired of checking the GetIt Package Manager for it.  I'm disappointed. And I'm concerned that these kinds of failures may reveal that Embarcadero's development processes are underfunded and broken. 

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

3 hours ago, Dave Novo said:

This is as known problem on complex projects. We have the same things and sent the logs to EMB. Essentially, the LSP parser is taking too long to compile the code. Because it is taking so long, the LSP parser thinks there is a problem and restarts. This happens over and over again.

 

I was not able to get the logs to EMB before Delphi 11 was in beta and David Millington said they could not fix it in time for Alexandria. We reported the problem in Delphi 10.4.2 but evidently according to David, and now your experience, it still persists in Delphi Alexandria.

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.

9 hours ago, Mohammed Nasman said:

You should take a deep look into it, it's really very powerful framework to build web applications with Delphi using ExtJS framework for frontend.

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

www.unigui.com

On 9/9/2021 at 1:32 PM, Uwe Raabe said:

OK, it is not official, but I will share some internals here. You can change the titles of the Welcome Page items to clickable links with a secret registry setting:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\22.0\WelcomePage]
"ActivateLinkOnTitle"=dword:00000001

 

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.

17 hours ago, rudy999 said:

I had not tried the F1 - but yet it does not open a specific version 11 help - it refers to 10.x

 

Doc Wiki link goes to Delphi 11 Alexandria page.

 

 

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).

33 minutes ago, Dave Nottage said:

If you can't wait for @dummzeuch to provide an updated GExperts, I have a DLL compiled for Delphi 11, here.

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...

1 hour ago, Lars Fosdal said:

For subscription users, both the web installer and the iso is available on https://my.embarcadero.com.

 

The details on what is new: https://www.embarcadero.com/products/rad-studio/whats-new-in-11-alexandria

 

Note that not all GetIt components have been updated for Alexandria yet.

Also - at the point of writing - the docwiki is down for the update.

 

It can be installed in parallell with 10.4.x or older, but remember not to mix your versions.

Forms modified in 11 may then break for 10.4.

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.

On 3/16/2021 at 8:15 PM, Jud said:

I've had problems with it, off and on, for the last few versions.  Seems like sometimes a build would fix it.  Sometimes going to another project and back would fix it.  But tonight it stopped working for me completely and nothing I tried (including deleting the DSK file) would fix it.

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.

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'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.