Devart Forums

Hi Evgeniy

Thank you for this information. We have now been able to confirm that

SQLConnection.Params.Values['SchemaName'] := 'test'

does work in a simple example program, and as a result we have then been able to address the issue in our software.

Thank you very much for your support. We would politely suggest that the documentation in your README could be updated to make it a little clearer, as despite the fact it does state that the "new" way of doing things (RAD Studio 2007 and onwards) is as above, the subsequent examples for each option (e.g. SchemaName) still refer to the "old" style of doing things (RAD Studio 2006 and earlier) and as a result this did cause us a little bit of confusion. It would be great also if the documentation could be accessed from the Help menu in the RAD Studio IDE, as this would highlight the fact that such extensive documentation is available (we had overlooked this).

Many thanks again for your excellent support on this issue.

Best regards,

Barrie

Hi Evgeniy,

Thanks for this very useful reply. We had overlooked the fact that this advanced documentation existed in the README file.

However, we are still having some issues. We are working in Delphi 11.0 Alexandria, and so the comment

Starting with CodeGear RAD Studio 2007 you should assign parameter values to TSQLConnection and TCRSQLConnection at run time in this way:

SQLConnection.Params.Values['Option Name'] := 'Option Value';

suggests to us that we should be calling something along the lines of:

SQLConnection.Params.Values['SchemaName'] := 'petrog'

However, this or similar attempts such as

SQLConnection.Params.Add('SchemaName=petrog');

are having no effect. Can you confirm that this is the correct approach? The alternative suggestion, which is suggested as only being applicable when setting extended driver options in Delphi 2006 and lower IDE versions, is

const
coSchemaName = TSQLConnectionOption(28); // string
. . .
SQLConnection1.SQLConnection.SetOption(coSchemaName, Integer(PChar('test')));

For us, this code does not currently compile. If this is the code we should be basing our solution on, what units would we need to add to the 'uses' list in order for this to work?

With thanks and best regards

Barrie

Hello,
We are experiencing an issue with the latest version (v5.1.1) running with PostgreSQL 14, compiling under Delphi 11.0 Alexandria.
We have migrated the data in our database from the 'public' schema to our own schema called 'petrog'. Having done this, we have then dropped the tables in 'public', so the tables only exist in 'petrog'. When we connect to the database, we use SQL to set the search path:

SQLQueryFieldDef.SQL.Add('ALTER DATABASE petrog SET search_path TO petrog,public;');
SQLQueryFieldDef.ExecSQL;

Having done this, if we then immediately call

SQLQueryFieldDef.SQL.Add('SHOW search_path;');
SQLQueryFieldDef.Active := true;
s := SQLQueryFieldDef.fields[0].Value;

then s is returning as 'public', not 'petrog,public'. As a result, our software is then unable to write data to any table e.g.

EUpdateError details: relation "windowposn" does not exist

as it is looking in the 'public' schema where no tables exist, whereas it should be looking in the 'petrog' schema. Every table has an associated TSQLTable component, and the 'SchemaName' property for each of these is set to 'petrog'.

We have also tried

'ALTER ROLE petrog SET search_path = petrog,public;'
and
'ALTER ROLE postgres IN DATABASE petrog SET search_path = petrog,public;'

with the same result.

So our question is - why is the search_path failing to set correctly when we execute any of the above SQL statements in our software which uses the DBExpress drivers? If we execute the exact same SQL statements in PGAdmin, the search_path is then set correctly.

Can anyone help? It would be greatly appreciated!

Barrie Wells

Alex - I haven't heard back from you since my last couple of emails to you on this matter. If you want me to re-send or post the details here, that's fine, but we really do need a full solution to this. Thanks!

Thanks for looking into this! Can I ask when the next version of the drivers, containing this fix, will be released? We cannot deploy our application built under 10 Seattle until this is resolved.

Many thanks!

We have come across a problem in the recent versions of Delphi, XE8 and 10 Seattle, that there is a memory leak reported when we exit our application. We have raised this with Embarcadero, but I am posting here also in case anyone can help, or at least say that they have had the same problem also?

The leak can be reproduced with a very simple two line program:

SQLQuery1.SQL.Add('SELECT columns.table_name, columns.column_name FROM information_schema.columns'
+ ' WHERE columns.table_schema = ''public'' ORDER BY columns.table_name, columns.column_name;');
SQLQuery1.Active := true;

Adding this simple block of code to a FormCreate, for a form with TSQLQuery and TSQLConnection objects with properties set up so that a connection to a database is successful, gives a memory leak (as reported by EurekaLog). Here is an excerpt from the call stack:

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|Methods |Details|Stack |Address |Module |Offset |Unit |Class |Procedure/Method |Line |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|+Leak #1: Type=Data at $0700AE40; Total size=512; Count=1 |
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|00000002|04 |00000000|0083CA20|Project4.exe|0043CA20|Data.DBXDynalink |TDBXDynalinkDriverCommonLoader|LoadDriverLibraryAndMethodTable |873[24] |
|00000002|04 |00000000|0083C6CF|Project4.exe|0043C6CF|Data.DBXDynalink |TDBXDynalinkDriver |LoadDriver |769[5] |
|00000002|04 |00000000|0083F46C|Project4.exe|0043F46C|Data.DBXDynalinkNative |TDBXDynalinkDriverNative |CreateConnection |87[1] |
|00000002|04 |00000000|0078D8EB|Project4.exe|0038D8EB|Data.DBXCommon |TDBXConnectionFactory |GetConnection |6661[12] |
|00000002|04 |00000000|0078D801|Project4.exe|0038D801|Data.DBXCommon |TDBXConnectionFactory |GetConnection |6640[0] |
|00000002|04 |00000000|007183E5|Project4.exe|003183E5|Data.DB |TCustomConnection |SetConnected |3567[8] |
|00000002|04 |00000000|00829241|Project4.exe|00429241|Data.SqlExpr |TCustomSQLDataSet |OpenCursor |4066[2] |
|00000002|04 |00000000|0072BC91|Project4.exe|0032BC91|Data.DB |TDataSet |SetActive |12470[12] |
|00000002|04 |00000000|00868C68|Project4.exe|00468C68|Unit6 |TForm6 |FormCreate |35[6] |
|00000002|04 |00000000|006C6295|Project4.exe|002C6295|Vcl.Forms |TCustomForm |DoCreate |3758[3] |
|00000002|04 |00000000|006C5EB5|Project4.exe|002C5EB5|Vcl.Forms |TCustomForm |AfterConstruction |3642[1] |
|00000002|04 |00000000|006C5E65|Project4.exe|002C5E65|Vcl.Forms |TCustomForm |Create |3632[35] |
|00000002|04 |00000000|006D0DEA|Project4.exe|002D0DEA|Vcl.Forms |TApplication |CreateForm |10557[13] |
|00000002|04 |00000000|008755D5|Project4.exe|004755D5|Project4 | |Initialization |23[3] |
|00000002|03 |00000000|76F17BFC|kernel32.dll|00017BFC|KERNEL32 | |BaseThreadInitThunk | |
|00000002|03 |00000000|7769AD1D|ntdll.dll |0005AD1D|ntdll | | (possible RtlInitializeExceptionChain+141)| |
|00000002|03 |00000000|7769ACE5|ntdll.dll |0005ACE5|ntdll | | (possible RtlInitializeExceptionChain+85) | |
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|


We are not suggesting that the Devart DBExpress PostgreSQL driver is leaking memory - it appears that we have simply uncovered a memory leak in Embarcadero's source code used in XE8 and 10 Seattle. Running the same exact code in XE7 does not give the leak (and we have tried using the last few versions of the Devart DBExpress PostgreSQL driver i.e. all combinations of driver version and Delphi version, and regardless of what driver version we use, the leak only occurs in XE8 and 10 Seattle, and never in XE7).

If anyone can shed any insight into this issue it would be much appreciated!