Zeoslib Portal

I've been using the OleDB protocol driver exclusively for MS SQL Server and it works very well. I ran a test using the OleDB protocol choice but changing the provider to the provider for ODBC (which I normal use through the ADO protocol choice) and got an error when it makes a query of: SELECT DATAB...

In general if you need to keep a dataset outside of the database connection the solutions are TClientDataset or TFDMemTable (there are some others as well btw.) I'd actually love if Zeoslib had a virtual dataset, or had some way to keep data after disconnect. It seems like all the pieces are there t...

I've tested the fix (latest r7020) on all my drivers and it seems to work perfectly, completely solving the original problem. I tested:

Oracle clients (11, 12, 19)
PostgreSQL
MySQL
Firebird

Tested on both 32bit and 64bit, Windows 10, Delphi 10.4. Thanks for the fix!

-Mark

Very cool! It seems you have things in hand, but to answer some questions: I only use absolute paths. All database client dlls are in separate directories and generally not in the system path. I've only seen the issue going from Oracle to PostgreSQL (I do use SQLServer but only though OleDB) I'm usi...

I just tested with Oracle 19.8 and I still have the same issue. I also tried the 11 and 12 Oracle clients and they all had the problem. I'll probably use one of these solutions (either setdlldirectory or LWASP) in my own version just to solve my local problem. It might be something to keep in mind i...

Another option is to just use:
This seems to do the same thing but without needing either SetCurrentDir or SetDllDirectory.

-Mark

After going down a rabbit hole of research, I modified TZNativeLibraryLoader.ZLoadLibrary and changed the SetCurrentDir to SetDllDirectory instead and it seems to solve the problem for me! if newpath <> '' then begin SetDllDirectory(PChar(newpath)); { Original code: temp := GetCurrentDir; SetCurrent...

Thanks! The versions are: Zeoslib Version: 8.0.0-beta Oracle Client Version: 19.3.0 PostgreSQL Client Version: 10.0.13 Could it relate to Oracle and PostgreSQL drivers both using some other dlls but different versions? This is a total guess on my part, but my thoughts went to different versions of t...

It appears that if I connect to Oracle, then attempt a connection to PostgreSQL in the same application, I get an error when LoadLibrary for the postgresql driver is called. System Error. Code: 126. The specified module could not be found. However if I connect to PostgreSQL first, then connect to Or...

Thank you for the new fix related to the RETURNING INTO clause! Tested and verified the fix. I've also noticed one other issue. If a stored procedure has a VARCHAR2 parameter, the "paramcheck" TParam DataType will be defined as ftWideMemo (which seems correct since they could be 32k max.) ...

Thank you! Tested and it's fixed in all my tests except the following which I think is a separate issue. Thank you for the tip on param size! // Just testing "returning into" clause which can be used on insert, update or delete statements. ZQuery.SQL.Text := 'DELETE FROM EMP WHERE EMPNO = ...

Hi All! I'm using some input and output params in a PL/SQL anonymous block and I'm seeing some strange issues. It appears that ptInput params that are strings need to be ftWideString type, but ptOutput params need to be ftString type (or they come out as incorrectly encoded strings with embedded #0 ...

Aha! Michael, thank you for that! Adding "MARS Connection=True" to my database string works perfectly! I've very glad I asked here before making a bug report. I'm no expert on the OLEDB stuff and appreciate the help!

-Mark

The error occurs on Query.Open, so it doesn't appear to be affected by using FetchAll instead of looping. Here's a test console app that shows the error (at least for me.) Would love to hear any thoughts, thanks! program ZeosSQLServerTrans; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, ZDbcInt...

Hi All! I'm doing some testing with the 7.3 beta and SqlServer. I'm using the oledb driver as from my research it appears to be the correct one to use for recent SQL Server releases. I haven't been able to get transactions to work properly with it and have had to fall back to always using autocommit...