Re: MaxLongVarcharSize=8190;

________________________________

From: Joel Fradkin [mailto:jfradkin(at)wazagua(dot)com]
Sent: 22 July 2005 13:31
To: Dave Page; pgsql-odbc(at)postgresql(dot)org
Cc: ac(at)wazagua(dot)com
Subject: RE: [ODBC] MaxLongVarcharSize=8190;

Thanks Dave,

I guess there is no down side to allowing the users longer text
fields for notes then.

I was testing the libpq driver yesterday doing stress tests from
our web app and did not see any leakage.

I also did not see any errors (My test server is not very
robust, so I could only get like 4 concurrent users working using the
web stress tool from MS before the site itself stopped being happy). I
do plan to get a robust server to test on next week and can grab the
latest snapshot.

Thats promising.

I am a little unclear on the questions about postgres headers,
do I just go find the source for that and put the headers in my project.

Install the pgInstaller version of PostgreSQL on your machine, using the
default locations (making sure you include the developer options), and
the required headers should be found automatically when you build
psqlODBC.

I am compiling under .net (the version I tested was I believe
all the latest and greatest from csv).

I can try switching back to vc++ vrom studio 6 if that is the
concensus and use the mak file as you recommended.

It has been several years for me to do compiling from the
command line in C++, so I feel more comfortable in the IDE.

Well, it's entirely up to you, but given that the only commands you'll
need once you've run vcvars32.bat are:

nmake /f win32.mak CLEAN

nmake /f win32.mak

copy release\psqlodbclibpq.dll c:\windows\system32

I'd be inclined to stick with what's known to work!

I am concerned about trying to convert to unicode and the new
drivers again, because last time my tests went smoth (using the non
libpq driver) and in production it fell like a punctured blimp. I
wasted like 18hours of my time (not totally least I have a current data
set in unicode to test with).

In what way? Is that what was crashing in the night?

I have not tried the new drivers with SQLASCII database, so I
will see what it does with that (if its like the non libpq driver it
will not display the french properly unless it's a unicode data base).

I was also unclear what you meant by -4 (SQL_NO_TOTAL)?

I believe it means there is no limit to the size, however I've never
tried it, and have no idea what'll happen to the performance.

Regards, Dave.

I am concerned about trying to convert to unicode and the new drivers again,
because last time my tests went smoth (using the non libpq driver) and in
production it fell like a punctured blimp. I wasted like 18hours of my time
(not totally least I have a current data set in unicode to test with).

In what way? Is that what was crashing in the night?

I am not sure what was crashing us at night (or daytime for that matter).

Interestingly the catastrophic error I got when I had the permissions wrong
for debug is the same one we got most of the time, so maybe its something
weird with permissions.

I did test the libpq driver with the SQLASCII and found it displays ? marks,
so I guess I have to convert to Unicode (which is what I wanted to do anyway
to make sure upper and length etc work properly).

I also tested various lengths of text with both the older driver (seems to
be 100k limit before the record set complains in asp) and newest libpq (did
not seem to mind any length tested with a 1 meg text test data insertion and
editing in asp). In my connect string in both cases (older and newer
driver)I had the max length

Current settings

MaxVarcharSize=254;MaxLongVarcharSize=16280;
TextAsLongVarchar=1;UnknownsAsLongVarchar=0;

set to 16K so I guess that is not what determines what the recordeset can
work with.

So far only good news on the testing of the new driver. I will try to get a
production box (2 proc 2650 4 meg) up for IIS and set up a test Unicode
database on my 4 proc Dell redhat postgres box for doing a bit more in deph
testing next week.

Joel