[patch_done] single quotes in queries

[joycekai]

Yay, it works! I did not test it extensively, but I was able to post a single quote with no problems, where it gave me a problem before.

Is this particular version I downloaded (2161) stable enough so that I can continue using it? I am getting ready to test my software prior to a release. What is your advice on continuing to use this? Can I be notified when a stable version that contains this fix is posted, or must I just keep checking back?

I had a little trouble finding the URLs, so in case anybody else has the same problem (or I have it again in several months), here is what I did:
The change log for this fix is located here:
http://sourceforge.net/p/zeoslib/code-0/2161/
I downloaded the complete set of files for the Zeos package that included this fix here:
http://svn.code.sf.net/p/zeoslib/code-0 ... sting-7.1/
FIrst I made a folder structure on my PC identical to my 7.0.3 package.
I used SVN repo-browser, which made it easy to download all the files in a folder. Everything was downloaded into the corresponding folder.
Click the Packages link and download the appropriate package
Click the src link and download Zeos.inc
Download everything in component, cord, dbc, parsesql, and plain.
In Delphi, go to Component - Install Packages and remove the existing Zeos package.
Go to File - Open and open the new zeos package. Follow the same directions to install it as for zeos 7.0.3. (There is a PDF in the doc folder.)
Go to Tools - Options and remove the zeos paths from the library paths. Then add the ones for the new zeos package. (The build folder is not done until you install the new package.)

Sorry to get so basic, but the step about library paths is REALLY important. The first time I tried it, it didn't work, but then I remembered that I needed to change the library path too!

[EgonHugeist]

joycekai,

nice to see it works!

I did not test it extensively, but I was able to post a single quote with no problems, where it gave me a problem before.

Do it! Backslash's are equal tricky like Quote-Chars.

s this particular version I downloaded (2161) stable enough so that I can continue using it? I am getting ready to test my software prior to a release. What is your advice on continuing to use this? Can I be notified when a stable version that contains this fix is posted, or must I just keep checking back?

I personally see no reason for scuble. I made some features like a reform for unlimited string-field sizes, and a Real-PreparedStatment for SQLite. The most other patches are bugfixes which will be backported to 7.0.4 soon. 7.1.x will be reeased at the first quarter of this year i think. So don't worry about using 7.1 for production -> welcome to the testers group.

Next step should be you go to SF.NET and suggest to close your ticked. Please reference to the patch i made.

Some more details accordingly my patch:
We've got a three way escaping sequence for PostgreSQL now. I'm using PQEscapeStringConn if possible, or PQEscapeString (deprecated) if you do not change the Client-Settings not equal to the Server-Settings. Last methode is the Zeos internal escaping function which is able to handle different CharacterSets but some Postgre-Spezials like BackSlash_Quotes are misssing.

Hints:
Use TZTable/TZQuery.Options := coPreferePrepared; This activatetes possible two Prepared statments. The CAPI Prepared statements (available since PG 8.0) don't need such escaping stuff and is propably faster. I know i could write this suggestion a loads earlier but then the bug, you've pointet me to, will be remaining. I'm thinking about omiting the emulated stuff for PostgreSQL and SQLite..


So thanks for the detailed explainations, i hope others read your details.

[joycekai]

Unfortunately, when I went to use the patch with my software, something in it is now broken and does not work.
I have several databases that the software needs to use, and so in each database I have a version table with a 'kind' field. The kind field in each is varchar and contains a string indicating the kind. When starting up my software I always check to make sure the correct value is in the kind field for all the databases. This always worked correctly before, and I did nothing to change the software or databases other than installing the updated Zeos.
This code has stopped working for 2 "kinds" of the databases. For the 3rd one it still works fine. For the ones that do not work, a blank string is returned. All the other fields in the record are returned just fine.
After some research, I figured out that the SQL to create the kind field is slightly different in the 2 "kinds" of databases.
The one that does NOT work is
CREATE TABLE version (
inx serial NOT NULL,
kind character varying,
major real DEFAULT 0,
swver real DEFAULT 0,
last_backup timestamp without time zone,
last_change timestamp without time zone
);
The one that does work is
CREATE TABLE version (
inx serial NOT NULL,
kind character varying(50),
major real DEFAULT 0,
swver real DEFAULT 0,
oemver smallint DEFAULT 0,
last_backup timestamp without time zone
);
Is it possible to make the zeos code work with the varchar field that does not have a limit? Version 7.0.3 worked with it.

[EgonHugeist]

joycekai,

Well this might be possible (; I've closed a Mantis-Bug where a varchar field without length spezifications should be haandled equal to text. So i switched this field-type to a Memo-Stream. Sufficient to close the old bug-report but i didn't check if it is readabe.

I'll check this issue tonight (; No proben with SVN i guess.

[miab3]

EgonHugeist,

For me it works well for PostgreSQL,
but could you make an additional parameter:

textlengthlimit = 255

for PostgreSQL and SQLite was a possibility to restore the old behavior.
Once the already discussed for SQLite

Michal

[joycekai]

I assume this means that the length of the data in the field would be limited to 255 bytes if the length is not specified?

[EgonHugeist]

joycekai,

You assume Michal's proposal corectly. Yesterday night i've tested to work with the unspezified varchar lengths as Memo field. I can confirm Michal's behavior. I have no problems too.

miab3,

I do welcome your proposal. But i suggest we should add a enum type for the TZDataSet.Options and your proposal for the TZConnection with highest precedence. Than we can get the old behavior.


Unclear is the name vor me... Text-Lobs should be allways threaded as Memo fields. But we're talking about Varchar-Fields with undefined lengths.

Proposals are welcome! CoUndefVarcharAsString/Undefine_Varchar_AsString-? I've not a real idea for shorter name and a clean purpose. If we have this option than we can swith the SQLite behavior too.

What you guys are thinking about?

[joycekai]

Right now my project is dead in the water because I don't have a bug-free version of Zeos that I can run it with. I hope what you are discussing will not take a long time!
I believe you are saying that it is somewhat strange to have varchar fields without a limit. I agree. I did not mean to do this. When I manually created the database the first time, pgAdminIII let me create these fields without limits, and I never noticed until now, because it always worked before.
The implications of the solutions you are discussing are not completely clear to me, but hopefully what you are discussing would involve no changes on my part -- I would just be able to read those fields with no changes to my database or code.

An alternate solution would be for me to update the database to include limits on these fields. However, I need to figure out the SQL to do this, and make sure I can do it without having to delete and readd the field.

[EgonHugeist]

joycekai,

I made a quick patch for you. R2168 \testing-7.1 (SVN).

Add 'Undefined_Varchar_AsString_Length=255' to the TZConnection.Properties, reconnect and you have the old behavior back.

I hope i'll have timm to check the behavior with PG8.1 this weekend.

Can you please test my patch?

[joycekai]

By the time I went to get the files, they were already at rev. 2169. Is it OK to use that one, or should I ask my SVN guru to show me how to get exactly 2168?

[EgonHugeist]

joycekai,

Each increased version is ok too, but i would like to see the guru (((;

Hope your issue is resolved then...

[joycekai]

Actually, I went and looked at the change log, and it looks like 2169 is the revision that you did.

As before, it took me a few minutes to figure out exactly what I was supposed to do to follow your instructions. For someone else reading this (or me in 3 weeks, I already had to go back and look at my previous instructions for downloading the update)...
Look at the TZConnection in the object inspector. Find the "Properties" property and click the ... button. Add a new line and type
'Undefined_Varchar_AsString_Length=255'
Obviously, this property is a stringlist, so it could also be done in code.

And, with that, hooray, it works, and I can once again read the value in VARCHAR fields that do not have an explicit length set.

Now I will go and test the single quote fix much more extensively using my project. I was going to do this before closing out the bug report, but I see that you have already closed it.

By "guru" I mean the guy at the next desk who is our SVN expert. Everybody needs a few good gurus.

P.S. Is there any documentation anywhere of what can go in that Properties property? Or any documentation of Zeos such as a user manual or help file?

[EgonHugeist]

joycekai,

2169 is the revision that you did.

This patch was for another issue: http://zeos.firmos.at/viewtopic.php?p=16927#16927
Your patch was 2168. RightClick the directory where your SVN is located, goto 'Tortoise SVN'->'Uptate to Revision'. Than you can choose the rev you want.

Obviously, this property is a stringlist, so it could also be done in code.

I agree partialy. Imagine Zeos is made for the most recommond RDBMs. Each provider has his spezial implementation. Since Zeos uses the Interface code base you can handle each spezial property in a Common-Component. Such options currently where submitted as Strings and each DbcConnection (Dbc-tier/layer) checks them. Another eventually faster way would be a Pointer to a common OptionRecord with a Pointer field which can be a second record. But the current codebase exists since years and somebody has to do this job. Our current two man team has his jobs, family and doing that for free.....

ow I will go and test the single quote fix much more extensively using my project. I was going to do this before closing out the bug report, but I see that you have already closed it.

Well i did it because i suggest some posts earlier you can do this. The current varchar issue was a complete new thing. The most people to post once, twice and ..... they give up if a solution/reply comes in 10 min. I'm sorry for closing the ticked, but i was starting from the premisse you won't close it. The whole discussion about bugs should happen on SF.NET. Next times i'm a little bit more patiant! ((:

P.S. Is there any documentation anywhere of what can go in that Properties property? Or any documentation of Zeos such as a user manual or help file?

Hmpf my english isn't good enough to write such documantations or wikis and i'm bussy with such threads like yours or forward developing. We can use the FPC/FreePascal wikis for Zeos things too, i think. But nobody helps in this domain. Everything is better than nothing as where i'm starting from. May i invite you to start theire? On the other hand we've the code and the most purpose is written theire. Second option would be th doxygen docs on SF.NET.

[joycekai]

OK, I have tested the fix some more, and it seems to work very well with no additional bugs introduced. Thank you very much for all your assistance!!

A little clarification. When I said
"Obviously, this property is a stringlist, so it could also be done in code."
I did not mean you (the zeos package developer), I meant me (the person using the zeos package). However, I think it is a better idea to do it in the object inspector.

I also did not mean that you should be writing documentation. Obviously, developing and maintaining the source code is much more important. I was just wondering if you knew where there was any good documentation, and especially if there is any "official" documentation. I will go look in those spots.

Again, thanks very much for all your help. You have been very patient and responsive.

[miab3]

EgonHugeist, joycekai,

Fact.
Although it would be handy to collect and describe the use of possible String Properties.
What are and what should have values​​, because practically to be seen.

Michal