Thread: MaxLongVarcharSize=8190;
When I pulled my connectionstring from the dns builder I got
MaxLongVarcharSize=8190;
We had data in our SQL database in text fields longer then 8k.
When a client tried to acces that record we got an error so I upped the MaxLongVarcharSize=8190; to
MaxLongVarcharSize=18190;
This fixed the problem, but I have been told by a conulting group (PCM) that using over 8 k might be causing my errors.
I did change it back to 8k and am a bit subjective on the outcome (we still have been having issues, but not odbc related).
Does anyone know the correct settings for my connection string to use longer then 8k text fields, or do I need to divide the data across multiple records?
Current settings
MaxVarcharSize=254;MaxLongVarcharSize=8190; TextAsLongVarchar=1;UnknownsAsLongVarchar=0;
Joel Fradkin
From: pgsql-odbc-owner@postgresql.org [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Joel Fradkin
Sent: 21 July 2005 22:34
To: pgsql-odbc@postgresql.org
Subject: [ODBC] MaxLongVarcharSize=8190;When I pulled my connectionstring from the dns builder I got
MaxLongVarcharSize=8190;
We had data in our SQL database in text fields longer then 8k.
When a client tried to acces that record we got an error so I upped the MaxLongVarcharSize=8190; to
MaxLongVarcharSize=18190;
This fixed the problem, but I have been told by a conulting group (PCM) that using over 8 k might be causing my errors.
Err, why exactly? As far as I'm aware, that option has always worked properly.
I did change it back to 8k and am a bit subjective on the outcome (we still have been having issues, but not odbc related).
Does anyone know the correct settings for my connection string to use longer then 8k text fields, or do I need to divide the data across multiple records?
Set it to whatever you need. iirc, you can also use -4 (SQL_NO_TOTAL) if you like.
Regards, Dave.
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.
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.
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.
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).
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)?
Joel
-----Original Message-----
From: Dave Page [mailto:dpage@vale-housing.co.uk]
Sent: Friday, July 22, 2005 3:56 AM
To: Joel Fradkin; pgsql-odbc@postgresql.org
Subject: RE: [ODBC] MaxLongVarcharSize=8190;
From: pgsql-odbc-owner@postgresql.org [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Joel Fradkin
Sent: 21 July 2005 22:34
To: pgsql-odbc@postgresql.org
Subject: [ODBC] MaxLongVarcharSize=8190;When I pulled my connectionstring from the dns builder I got
MaxLongVarcharSize=8190;
We had data in our SQL database in text fields longer then 8k.
When a client tried to acces that record we got an error so I upped the MaxLongVarcharSize=8190; to
MaxLongVarcharSize=18190;
This fixed the problem, but I have been told by a conulting group (PCM) that using over 8 k might be causing my errors.
Err, why exactly? As far as I'm aware, that option has always worked properly.
I did change it back to 8k and am a bit subjective on the outcome (we still have been having issues, but not odbc related).
Does anyone know the correct settings for my connection string to use longer then 8k text fields, or do I need to divide the data across multiple records?
Set it to whatever you need. iirc, you can also use -4 (SQL_NO_TOTAL) if you like.
Regards, Dave.
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.
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