I've patched the binary data issue (rev.1725) and enabled the CAPI statement back. Delphi tests seem to pass well, but something happened to my Lazarus (ztestall crashes), so I can't check if everything is fine in there.
So let's say activating the Real-prepared statments isn't mad for such statements/dummies... Or do you see a generic way to know if such a statment is preparable or not? Can tell us postgres something about previously? If the statment is not able to prepare then we avoid the prepare stuff and send the statement with PQexecParams (Btw why was it not done before?)
There is nothing we can do to check if the statement is preparable, so the user has to control parameter types manually, if he prefers prepared statements
I've patched the binary data issue (rev.1725) and enabled the CAPI statement back. Delphi tests seem to pass well, but something happened to my Lazarus (ztestall crashes), so I can't check if everything is fine in there.
Had a look right now. Great job again. Damn i like it. But why do the LAzarus tests crash now? Since activating this statment? Didn't run them since two weeks.
There is nothing we can do to check if the statement is preparable, so the user has to control parameter types manually, if he prefers prepared statements
I have also no clue. Every improvement will fail, i'm sure... So let's keep that statment optional. Oleg is it possible to use PDouble pointers instead of string converted floating values? the paramvalues array is an array of pointer to 0# terminated strings. On other plaindrivers we can do this and avoid loosing some precision. Just a question.
But why do the LAzarus tests crash now? Since activating this statment? Didn't run them since two weeks.
No, I don't think so. I'll try to make a clean build of everything (Freepascal, Lazarus and Zeoslib) to make sure it's not problem on my side.
Oleg is it possible to use PDouble pointers instead of string converted floating values? the paramvalues array is an array of pointer to 0# terminated strings. On other plaindrivers we can do this and avoid loosing some precision. Just a question.
Yes it's possible, but it's a big peace of work. The internal structure is described in C-sources of PostgreSQL and it looks scaring to me )))
No, I don't think so. I'll try to make a clean build of everything (Freepascal, Lazarus and Zeoslib) to make sure it's not problem on my side.
did run a fulltest with FPC2.6/LCL1.0RC2 32/64 no new issues to see. One hint, Oleg: You do not need to install the components for the testsuites. On the otherhand you have allways to recomplie Lazarus.
Yes it's possible, but it's a big peace of work
Oh that would be great. I know with floating values are allways some issues remaining.
The internal structure is described in C-sources of PostgreSQL and it looks scaring to me )))
Yep, that i can confirm. It seem's for me also the FPC core has his problems to interpret the Postgre code right. Just have a look to the FPC postgre definitions if PQprepare/PQExecPrepared they are simply wrong. But i must admit as i added the arrays which you have completed it was much more a logical feeling then knowing they expect arrays. I couldn't see that on the Postgre header files... Anyway if we could get PQdescibePrepared running and can point allways to the right values like we have that on FireBird then everything should be 100% save.. I know this can be a lot of work, Oleg.
Oh if i could then i would show you reports. I know this from LudoB, a great FPC coder. It might be possible that this is only a fpc issue? No i didn't mean the formate DBC fieds. As far as i know do they use double precision too. LudoB is in our ZeosDeveoper group. You can contact him, otherwise forgett about it. Eher actual state is a teriffic thing, i think.
Oleg did you had a look again to Mantis? I can grant you a deveoper state there too. It would be great if you can check the remaining postgre/firebird issues too. Mark added a sf.net bugtracker for the deveoper group again. There we write in assigned issues from Mantis and report if they are gone. The intention is to have a frech start with the bugtracker. Free free to help there too.
confirmed. I do also wonder why that happens @designtime.
else if (TypeName = 'INT') or (TypeName = 'INTEGER') or (TypeName = 'INT,') then
Hmm there must be an issue left with splitting the column informations in the metadata. I'll have a look there. You have to know MySQL does not have an extra columntable until 5.5(information_schema). So i was forced to read out a bad blob. I have an idea how to surround that issue, Michal. Is it possible you create the procedure like this?:
i've commited a fix for that. R1726. This INT, issue should be gone now (i hope so). Hae no time for deeper tests yet. Can you check it?
olehs,
Michael, I guess we need extra method in metadata to compose qualified identifier names.
Agree. Either this or a fix. I wonder why that not happens on TZTable...
But i have some other issues with the MySQL Identifier too -> they are not able to quote the strings. I expext a `as quoted identifier for my SQL. So also the unquoting dit fail there.. I've recognized it yesterday as i wrote the statment. Have to check this too tonight.