I just installed V2.39, which was released today and was concerned that the issues I had with V2.38 (the first version it seems listed as supporting D12) are still there.
The issue centres around Delphi 12's stricter enforcement of actual vs formal var parameters. Which means that
eg TEDBStaticRowValue.GetString(var Value: String);

calls Readstring or readfixedstring from the EDBCommon unit. However, Readstring defines the value passed as UnicodeString and readfixedstring as AnsiString.

Neither gets past the compiler. I looked at patching, but since the issue affect several EDB units, felt the level of patching was interently risky, and should have been done in the first D12 release.

So, the first question is: has it ever worked  in D12? If so, when did the issue kick in? Which leads into the lack of response regarding issues in these forums. Even 2.29 is not announced in the forum for new releases. I like others have large concerns as to the direction EDB is moving in, as a compile issue that large should be typically dealt with with speed.
Until resolution, I am forced to keep projects using EDB in D11, when other projects are already migrated to D12. I will not be extending the conversion of other projects to use EDB regardless of its stable reputation until and unless I can see a clear pathway.
I have seen other comments saying the company is working but slowly in the background. But there has been no formal response that I have seen from the company to address the growing concerns I see in other posts

Are you not able to compile into 12.3?  

I've not had any issues compiling either my own lightly modified EDB Server nor issues compiling projects or the components in 12.3.  (or any 12.x)

Lance


Jeff W wrote:

I just installed V2.39, which was released today and was concerned that the issues I had with V2.38 (the first version it seems listed as supporting D12) are still there.
The issue centres around Delphi 12's stricter enforcement of actual vs formal var parameters. Which means that
eg TEDBStaticRowValue.GetString(var Value: String);

calls Readstring or readfixedstring from the EDBCommon unit. However, Readstring defines the value passed as UnicodeString and readfixedstring as AnsiString.

Neither gets past the compiler. I looked at patching, but since the issue affect several EDB units, felt the level of patching was interently risky, and should have been done in the first D12 release.

So, the first question is: has it ever worked  in D12? If so, when did the issue kick in? Which leads into the lack of response regarding issues in these forums. Even 2.29 is not announced in the forum for new releases. I like others have large concerns as to the direction EDB is moving in, as a compile issue that large should be typically dealt with with speed.
Until resolution, I am forced to keep projects using EDB in D11, when other projects are already migrated to D12. I will not be extending the conversion of other projects to use EDB regardless of its stable reputation until and unless I can see a clear pathway.
I have seen other comments saying the company is working but slowly in the background. But there has been no formal response that I have seen from the company to address the growing concerns I see in other posts

> I've not had any issues compiling either my own lightly modified EDB Server nor issues compiling projects or the components in 12.3.  (or any 12.x)

I haven't had any problems either.  I recompiled the EDB Server engine for 2.39b1 yesterday using Delphi 12.3 without any issues.  

My only change was to use FastMM5 as the memory manager for the server engine.  If it helps anyone else, my early benchmarks show a measurable performance improvement over the standard server engine shipped with the product by about 10%.

Hi Terry,
Did you use FastMM5 as it comes or with some tweaks to the settings?
If you made some tweaks, care to share?

Regards,
Ian

> Did you use FastMM5 as it comes or with some tweaks to the settings?

Just optimized it for speed.  Call FastMM_SetOptimizationStrategy(mmosOptimizeForSpeed) as soon as possible in the initialization process.  

Noted with thanks.

> I've not had any issues compiling either my own lightly modified EDB Server

Quick side topic questions for you Lance.  How are you handling the versioning of the EDB Server?   Are you keeping the internal EDB file version number (2.39.0.1, etc) or managing something else of your own?  

Terry Swiers wrote:


> I've not had any issues compiling either my own lightly modified EDB Server nor issues compiling projects or the components in 12.3.  (or any 12.x)

>I haven't had any problems either.  I recompiled the EDB Server engine for 2.39b1 yesterday using Delphi 12.3 >without any issues.  

>My only change was to use FastMM5 as the memory manager for the server engine.  If it helps anyone else, >my early benchmarks show a measurable performance improvement over the standard server engine shipped >with the product by about 10%.

No, I found myself going through several units with the same sort of issue. Originally with the dec 2023 release, then installed the new version when I wrote the post. Both had the same multiunit issues:
eg TEDBStaticRowValue.GetString(var Value: String);

calls Readstring or readfixedstring from the EDBCommon unit. However, Readstring defines the value passed as UnicodeString and readfixedstring as AnsiString.

I would need to patch many lines of code and it should just install and run. The changes run a risk of creating more issues. I can't test if it ran in the first release of D12, moved on to 12.3 since then, but my research seems to indicate the stricter enforcement of variable types is a feature of D12 in general

Tim told me that he was going to post an announcement last weekend.  But it didn't happen.  <sigh>

= Steve

Hi Jeff,

Please send me an email detailing the issues that you're having (specific line #s in the source code, compiler settings).

There's definitely an issue with how you're compiling the source code.  We ship .dcus compiled with Delphi 12.x. as part of our products, which would be impossible if it didn't compile properly.

Tim Young
Elevate Software
www.elevatesoft.com