Yes i know this is an nightmare. But i was forced to introduce this option because of to many bugreports...Oh... now I understood the whole idea you put into PreprepareSQL processing.
I don't really know what to say... This seems like a big challenge. There can be so many issues like the one I patched at rev.1651. There was a query like
Code: [Erweitern] [mehr anzeigen] [Verkleinern] [Alles auswählen]
select id as Код from orders
and TWordState couldn't detect non-latin alias. And now according to what you said, ttWord has to be checked for Encoding. And there may be surprises also in DDL statements and so on.
I think as a developer that uses Zeos, for me is better to manually control that encoding of SQL and in-parameters were the same.
sounds ok for me. I'll add this type if i've the time. Thank you for your constribution, Oleg.I absolutely don't mind Smile. Couldn't do it myself because I'm not familiar with other databases' specific syntax.
I also think there is no need for extra token type in PostgreSQL. ttQuote (and maybe ttEscapedQuoted) is quite enough.
That would be great, Oleg. I did complete this Statement now and commited the Patch. Rev. 1657.If you need any help I will be glad to help you.
I was forced to keep the emulated statement as default. I did run all test we have with that statement now.
Steps to reproduce my deep test:
comment "and ( Self.FExecCount > 2 )" line 838 in procedure TZPostgreSQLPreparedStatement.Prepare; ZDbcPostgreSqlStatment.pas out. This activates that all statements with parameters where handled with 'PREPARE','EXECUTE','DEALLOCATE'. I did introduce an execution counter because the JDBC API works like this too and if this statment will be called only once then there are 2 steps to much here.
Also you need to open ZDbcPostgreSql.pas and go to:
function TZPostgreSQLConnection.CreatePreparedStatement(
const SQL: string; Info: TStrings): IZPreparedStatement;
Here comment everything out after lin 575 except Result := TZPostgreSQLPreparedStatement.Create(GetPlainDriver, Self, SQL, Info)
Then this statment is 100% the default one. All tests did run successfully except the tests: TestStandartConformingStrings because PostgreSQL is not able to determine the type of your introduced parameter. I wonder about again because all other Drivers do return here a string but PostgreSQL raises an exception.
To set this statement as default without modification use TZQuery.Options := [doPreferPrepared, doPreferPreparedResolver].
Then you can now execute all Parameter queries in Batch-mode which, i hope, should speed up the whole handling.
Also was i afraid about one thing: i did read in several JDBC examples that we do NOT need to escape the Strings. But i didn't get them running successfully without escaping.
This is also now the firs 100% AnsiString statement with String-handling which means for the FullUnicodeIDE's a lot of speed increase because of minior UTF8Encode/Decode the Strings. And it is 100% unicode save. (I already had all of them ready but the team decided to keep the old behavior)
I would be happy if you run some tests.. Or fix issues you can see. I don't feel tarnished here (:
Michael