Re: MaxLongVarcharSize=8190; - Mailing list pgsql-odbc

From Dave Page
Subject Re: MaxLongVarcharSize=8190;
Date
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E4AC9486@ratbert.vale-housing.co.uk
Whole thread Raw
In response to MaxLongVarcharSize=8190;  ("Joel Fradkin" <jfradkin@wazagua.com>)
Responses Re: MaxLongVarcharSize=8190;
List pgsql-odbc
 


From: Joel Fradkin [mailto:jfradkin@wazagua.com]
Sent: 22 July 2005 13:31
To: Dave Page; pgsql-odbc@postgresql.org
Cc: ac@wazagua.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.

pgsql-odbc by date:

Previous
From: "Dave Page"
Date:
Subject: [Patch] SSL Support
Next
From: tomas@nocrew.org (Tomas Skäre)
Date:
Subject: Static analysis run