EXE -> dll

[konsul41]

Sorry for my english - GoogleTranslator
Do you plan to move the barrier EXE-DLL
It's a case of:
connect the EXE and DLLs provide the interface to the dll and then use that interface.

In short, it was that of the substitution

As for the exchange

TZAbstractConnection = class(TComponent)
on
TZAbstractConnection = class(TComponent, IZConnection)
przy czym IZConnection powinien mieć pola TZAbstractConnection.

and

TZAbstractRODataset = class(TDataSet)


published
property Connection: TZAbstractConnection read FConnection write SetConnection;

on

published
property Connection: IZConnection read FConnection write SetConnection;

Of course we had to go to the data types String -> WideString, konwerska in Delphi is automatic.

It was good to lock drawing a connection identifier of IZConnection it closes the way for easy pulling the password to the database.

[EgonHugeist]

Hi,

I do not realy understand the purpose of your suggestions. AFAIU did you propose a patch of these components.

So what's wrong by using?

Code: Select all

TZConnection.DbcConncetion: IZConnection;
or
TZDataSet.Connection.DbcConnection: IZConnection;

[konsul41]

It's about crossing barriers Exe-dll (not BPL) for objects. Objects can not be moved from exe to dll and vice versa, only simple types.
The idea is to get some exe interface that represents TZConnection (replacement) and dll and create TZQuery him to enter the call and continue to use TZQuery as if it worked in the exe.
Optionally, create a dll and inject him TZConnection connection identifier, and we could use the connection pool server and operate with a single connection identifier in both the exe and dll. Good it would be to wykożystania the connectors and use a uniform system of both the exe and dll. This need not be modified, and can separate component TIZConnection and TIZQuery.

[konsul41]

The problem is
property DbcConnection: IZConnection read FConnection;
the dll is not
write FConnection;

[marsupilami]

Hello konsul41,

I think one easily could derive a class from TZAbstractConnection or TConnection where it is possible to set the IZConnection property. But even then one would have to be careful because the interfaces of the Zeos DBC-Layer use long delphi strings and things like that, which cannot be shared easily from a program to a shared library. To get around this, one would have to use the ShareMem unit and BORLNDMM.DLL. As I am no expert on this, I have to assume, that one also would have to use the same delphi versions for the DLL and the executable to get this working properly.

So - do you think that would suit your needs? Because I think everything else would require a lot of work on Zeos...

Best regards,

Jan

[konsul41]

Most simply had to go on a String -> WideString it is safe to use interfaces and TStream -> IStream.
Wim that a lot of work, especially testing, but I think it would be worthwhile, and the normal user does not know the difference.

Alternatively, you can make a method which would enter IZConnection to TZConnection, this solution is used in FireDAC and others.
The dll create TZConnection enter the connection identifier of the exe that has an open connection (after you select the database driver) and have an active TZConnection in dll (connection pool).

In addition, why the interfaces are used String instead of WideString . They are not safe at interfaces. Is there a problem with that?

[konsul41]

I added
TZAbstractConnection = class(TComponent)
...
property DbcConnection: IZConnection read FConnection write FConnection;


code exe:
function GetIZConnection():IZConnection;stdcall;
begin
result:=ksiegi.ZConnection1.DbcConnection;
end;
exports ...GetIZConnection;
end.

code dll:
function
...
Conn : IZConnection;
ZConnection : TZConnection;
Query : TZQuery;
begin
FGetIZConnection:=GetProcAddress(MainInstance, 'GetIZConnection');
if (@FGetIZConnection<>nil) then conn:=FGetIZConnection;
try
ZConnection:=TZConnection.Create(nil);
ZConnection.DbcConnection:=conn;
Query:=TZQuery.Create(nil);
Query.Connection:=ZConnection;
Query.SQL.Text:='SELECT * FROM stawkivat;';
Query.Open;
ShowMessage(Query.FieldByName('nazwa').text);
finally
Query.free;
Conn:=nil;
ZConnection.DbcConnection:=nil;
ZConnection.free;
end;

it works and gets the correct result of the query, but the question remains whether memory leaks occur.

[marsupilami]

Hello konsul41,

WideStrings are slower than DelphiStrings because Delphi uses a copy on write technology for its internal strings and because with AnsiDelphi there would be the need of conversion whenever a string is passed from the component layer to the DBC layer, I think.
Also I am not sure, wether Zeos maybe uses other things that are unsafe to pass between an exe and a dll like dynamic arrays or things like that.

With your solution you most probably will not get memory leaks but maybe you will get memory corruption because you have two memory managers reserving and releasing memory for Strings and other dynamic objcts like dynamic arrays.

Best regards,

Jan

[konsul41]

It can enter the connection identifier
IZPostgreSQLConnection = interface (IZConnection)
['{8E62EA93-5A49-4F20-928A-0EA44ABCE5DB}']
...
function GetConnectionHandle: PZPostgreSQLConnect;

and it was possible to have a seperate from DB layer exe dll and operates on the same connection identifier.

SetConnectionHandle function (handle: PZPostgreSQLConnect);


And what if the dll is written in Visual Studio, maybe it's not practical and passe, but I do not want to impose restrictions BPL as exe and dll must be in the same version.