Re: MaxLongVarcharSize=8190;

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Joel Fradkin" <jfradkin(at)wazagua(dot)com>, <pgsql-odbc(at)postgresql(dot)org>
Cc: <ac(at)wazagua(dot)com>
Subject: Re: MaxLongVarcharSize=8190;
Date: 2005-07-22 13:49:09
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E4AC9486@ratbert.vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

________________________________

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.

Responses

Browse pgsql-odbc by date

  From Date Subject
Next Message =?iso-8859-1?q?Tomas_Sk=E4re?= 2005-07-22 15:18:57 Static analysis run
Previous Message Dave Page 2005-07-22 13:27:56 [Patch] SSL Support