Zeoslib Portal

EgonHugeist,

I think complete absence of support is a bigger problem. Besides, implementing MySQL's CallableStatement, can lead to some global changes we'll have to make.

@olehs, @EgonHugeist

It seems that now the procedures in PostgreSQL work just as well as the FireBird.

Zeos7_branches_ testing_r1692
http://svn.code.sf.net/p/zeoslib/code-0 ... s/testing/
compiles and runs on (I have tested):

- D2006,
- D2007 -> C++,
- DXE2 32/64 -> C++32,
- Lazarus Win 1.1/fpc 2.7.1 32/64,
- Lazarus Lin 1.1/fpc 2.7.1 64 on Debian 64-bit (LMDE 201204).

Michal

olehs,

agree with you. I'll start to implement the CallableStatement fo MySQL. To avoid futher merges i've commited the unused and never tested TZPostgreSQLCAPIPreparedStatement. Feel free to test and fix it. I know about some issues and i'm not sure if i interpreted the PostgreSQL functions for that statement corectly. If you find the time then have a look there.

Also did i check the aditional tests you've made. Nice again, Oleg.

miab3,

good news again. I hope we can solve the remaining issues on that component too.

miab3, olehs,

had a bad start with MySQL. All metadata according stored procedures are missing there too. So i had more fun to complete the CAPI PostgreSQL real prepared statement. To activate it choose ZDataSet.Options = [coPreferePrepared] and minimum ServerVersion 8+.

Oleg, i was running into the same issue with such selects:
Query.SQL.Text := 'select :test'; if PostgreSQL can't determine the Field for the Parameter then we got the same Exception.

So i was forced keeping the emultated prepared as default again. Hmpff.

EgonHugeist,

Oleg, i was running into the same issue with such selects:

Query.SQL.Text := 'select :test'; if PostgreSQL can't determine the Field for the Parameter then we got the same Exception.


So i was forced keeping the emultated prepared as default again. Hmpff.

I was thinking about it. The only possible way to solve this problem is exemine PQdescribePrepared and specify ParamTypes for unknown types manually in PQexecPrepared.

olehs,

Thought this call works only with the return values. Hmm that should be checked. Firebird goes this way but i must admit i have'nt testet such a statement.

But i think this will not work again because we try to prepere aa statement like 'select $1' and in this case we only have the Zeos Parameter-type. Could that be enought?
If somebody assigns this param with AsString := '123' we can add a parametertype text but if someone uses AsInteger := 123; then we have an Integer field...

What do you think?

After my latest patch 1703 i have a new issue:
I added the statement Deallocation and all blob tests raising exception for "Server connection lost" Any ideas? If i comment the two lines in the Unprepare procedure everything is fine. But the statements where not released on server-side.

EgonHugeist,

I am not sure about PQdescribePrepared also, but docs say
The functions PQnparams and PQparamtype can be applied to this PGresult to obtain information about the parameters of the prepared statement

If somebody assigns this param with AsString := '123' we can add a parametertype text but if someone uses AsInteger := 123; then we have an Integer field...

Seems like a nice workaround for params of unidentified types.

After my latest patch 1703 i have a new issue:

I added the statement Deallocation and all blob tests raising exception for "Server connection lost" Any ideas? If i comment the two lines in the Unprepare procedure everything is fine. But the statements where not released on server-side.

Actually I get another error in the tests:

There were 2 failures:
1) TestRealPreparedStatement: ETestFailure
at
"postgresql-8_Unicode/postgresql-8: Different stream size. Expected: 1024. Actual: 2952.Binary Stream"
2) TestRealPreparedStatement: ETestFailure
at
"postgresql-8_Ansi/postgresql-8: Different stream size. Expected: 1024. Actual: 2952.Binary Stream"

@olehs, @EgonHugeist

Maybe before MySQL is worth to see why Zeos recognize (not always) the procedures for Oracle and MSSQL(ADO-SQLNCLI, FreeTDS) but throwing errors in the execution attempt.

Michal

olehs,

After my latest patch 1703 i have a new issue:
I added the statement Deallocation and all blob tests raising exception for "Server connection lost" Any ideas? If i comment the two lines in the Unprepare procedure everything is fine. But the statements where not released on server-side.

added a nice workaround and all prepared statements are released now. R1709

[s]Oh these test raising either exceptions on my side with D12_UP but why we've two fails now? But as far as i know did the TestVeryLargeBlobs crash for Oracle, PostgreSQL (and MySQL with server dependencies) since LudoB added them. This i do not understand yet...[/s]

wrong test, sorry.

Accordingly the test RealPreparedStatment i must say i have no such issues with my battary of compilers.. Sure you are up to date?

miab3,

Maybe before MySQL is worth to see why Zeos recognize (not always) the procedures for Oracle and MSSQL(ADO-SQLNCLI, FreeTDS) but throwing errors in the execution attempt.

That might be right. but i've allredy started now with the remainig MySQL part. Terrible trust me on that..

Accordingly the test RealPreparedStatment i must say i have no such issues with my battary of compilers.. Sure you are up to date?

Yes, just tried on Delphi7 and XE2 - same error.
Here are contents of both streams.

olehs,

did overwrite all locale files except the packages again. Recompiled everything. This makes me curious. I cant't confirm new issues. FPC,D7,D2007... XE2 starter everything is like expected. I had a look to both files. The first cutet testsring i know. The second file contains a Escapet version. But i wonder THIS kind of escaped binary was only used for PG7.3 down. Can you have a look to the statments and debug the issue?

EgonHugeist,

Ok, here's what I found.
When using FPlainDriver.EncodeBYTEA on stBinaryStream
in TZPostgreSQLCAPIPreparedStatement.BindInParameters
that binary stream is saved in db just as is (escaped).

I guess PQexecPrepared doesn't want binary data in Escaped format.
If you pass parameters as text (paramFormats[] = 0), then it has to be valid string data (for specified encoding), or you have to pass it as binary data.

olehs,

uff Oleg. i was only able to get binary data running WITH that function (my result looks like /x012034AF4....). So i guess we've different server settings here. Could it have dependencies to Standart-confirming-strings?

So it seems there is much more work left. In the last revs i dropped the ParamLengths, ParamFormats, ParamTypes in the statments and send only nil pointers.

First i want to find out why we've differences here. How can i read out my locale settings? Then we can compare them.

Next thing is i have now some other work todo and the MySQL issue is remaining too. So what do you propose? We could active the non CAPI Prepared statment as default until this statment is ready.

What do you think?

EgonHugeist,

let's compare our server settings using
SHOW ALL

olehs,

settings attached.