[patch_done] PostgreSQL64 + Lazarus 09.30.2+ windows 64 bit

[ism]

rev 1149

in Lazarus 64 bit with postgres 9.1 all working good (my tables without blobs)
if you want i test your test project in Lazarus

but with mysql 5.5 some problem , see up
i trace with wireshark , result causing the problem

Code: Select all

SHOW FULL COLUMNS FROM test. LIKE '%'

problem in incorrect create sql query in 64 bit (see in dot "test.")

but in 32 bit the same project

Code: Select all

SHOW FULL COLUMNS FROM test.new_table1 LIKE '%'

in this place TableNameList is null , but must be "new_table1"

[EgonHugeist]

ism, that problem i've found: ZCompatibility.pas see attachement.

Actually I'm testing the other Plaindrivers which also using the PULong before i'll commit the patch. You can test it. It works with MySQL64. It was more a feeling because the 64Bit servers actually using 32Bit dll's...

Confirmed?

[ism]

I test your patch , all working good !

And I spent 3 hours on the trace

[EgonHugeist]

But i've no ideas about the blobs actually. Because there where Pointers used. Or i try to boil the PPointers down to 32Bit.. I wrote Marcov for help concering the blobs.

3 hours! No problem with LCL the debugger is a problem for me too.

Now testing FB64 if it works, i'll commit that minior patch with a big effect..

[ism]

maybe replace QWord in patch in Int64 , potentially in 64 bit platforms increase the speed of operations in a 64-bit platforms because int64 is placed in a register. On 32-bit platforms, it as two words

[EgonHugeist]

No here i disagree. The FPC system.inc has allways higher precedence than then ZCompatibility.pas. And the Int64 size is 8Byte but the dll expects 4byte integers. So i see no way here. The longWord is in 32/64 Bit allways 4byte. I think it would be better to add a comment to the ULong type to avoid the change of somebody else again. What do you think?

If in further times a real 64Bit dll is comming out then it would be better to use new defines in the Zeos.inc or write a new 64Bit plaindriver.

Now i've installed Firebird64. They are still using the gds32.dll. So i think everything is fine again. Give me a half hour...

I'll inform you, ism.

[EgonHugeist]

Nope Firebird has problems too. Recompile LCL with the PTRINT...

Btw. the Blobs making trouble everywhere with FPC64 and Windows64

[ism]

Code: Select all

Btw. the Blobs making trouble everywhere with FPC64 and Windows64

Give me example project with database dump
For mysql or postgress

maybe problem with memory allocation

[EgonHugeist]

ism i always create a empty datbase which i connect. Then i acces mostly a system table

PG: select * from pg_stat;
mySQL: ???
Interbase: select * from RDB$Triggers.

Better proposal create a database ZeosLib or whatever for the Drivers. open the \database in you branch folder. There you'll find a create_xxx.sql files like create_mysql.sql . Use allways the table people... The definition is always right there. We use the scripts for the test suites.

Btw firebird runs. But also breaks on the blobs. So i'll commit the Patch. The blob problem happens everytime on the same line:

function TZRowAccessor.GetBlobObject(Buffer: PZRowBuffer;
ColumnIndex: Integer): IZBlob;
var
BlobPtr: PPointer;
NullPtr: PByte;
begin
BlobPtr := PPointer(@Buffer.Columns[FColumnOffsets[ColumnIndex - 1] + 1]);
NullPtr := PByte(@Buffer.Columns[FColumnOffsets[ColumnIndex - 1]]);

if NullPtr^ = 0 then
Result := IZBlob(BlobPtr^) <- end dead! Ideas? I've checked the assignemts before. -> Valid!
else
Result := nil;
end;

You can check the assigning in each plaindriver-special resultset in the function TZPostgreSQLResultSet.GetBlob(ColumnIndex: Integer): IZBlob; for example. You'll see the blobs are assigned. It doesn't matter if they are empty or not. (or the PByte NullPtr is wrong that could be possible too then we try to assign a unassigned Blob, damn that is possible!!!)

So it must be something wrong with the interface ref_counters or the BlobPtr points to nowhere...

[ism]

Maybe
some_var:=BlobPtr^
Result := IZBlob(some_var)

I have often solved the problem this way

[elidorio2]

Hello EgonHugeist,

News!!
Do you know why it appears the error Access violation?
Answer: This error generates because clientCodepage not been set.
Connected now normal. Serie useful to treat this error, if the clientCodepage is not set, send a message.

To what end;

Edson

[EgonHugeist]

Does that mean you assign the pointer to a Variant before assign as interface?
Then try it if helps. However we've to find a sulution. Got an answer from FPC. They don't an answer concering this used code... Hmpfff.

My feeling says: the nullPtr is the problem...

Btw. patch done Rev.1150 -> We can access now on 64Bit OS. Can you test it on Linux eventually?

[ism]

MySql 5.5 program crash with

Code: Select all

Unknown MySql Data type ! 

Linux 64 bit

In windows 64 bit rev 1150 working normally

it is strange

[EgonHugeist]

Grumle!!!

ism, does it work without my last change? then we only need a compiler define here!

elidorio2,



that's impossible! but anyway it works. Let us complete the workout to be stable here.

[ism]

rev 1149 mysql linux 64 all working , but not working in windows 64 bit :)

it is comedy