Thread: figuring out why I am having this issue
I do not mind researching the text field problem myself, but looking at the source code I have no idea where to look or how to approach this.
I have seen a few email where some of the developers talked about how they were getting feed back, but to be honest never paid much attention.
I can look in the archive (and probably will), but if any of you who has worked on the code could maybe point me in the right direction like which .c file would be looking at
MaxLongVarcharSize I did a search and only saw it referenced in one file and it does not look to me like it is doing anything with text fields, so I must be missing something.
Any ideas would be a big help.
Joel Fradkin
LOL. Thank you much for the info. I wish I were having a beer now myself. I will see what I can fingure out on my own (god forbid). I hope I did not sound like you guys don't help, I am a bit anal. MY boss is freaking and I don't have much in the way of an answer, but it will sort itself out in time. As always I do appreciate all the help I have gotten thus far and do not want to sound like I don't, because the people on this list are the best. Joel Fradkin -----Original Message----- From: Dave Page [mailto:dpage@vale-housing.co.uk] Sent: Wednesday, August 31, 2005 3:34 PM To: jfradkin@wazagua.com; pgsql-odbc@postgresql.org Subject: RE: [ODBC] figuring out why I am having this issue Joel, The problem is not that we won't help, but mainly I suspect we're in timezones some way east of you. For example, I'm watching telly, eating a popadom, and thinking about having a beer and going to bed!! (I'm also on my pda, and don't have the source right now). A hint though - look in the connectionstring in mylog, and find the actual option name/code. Then, look in options.c (iirc), and see if you can figure out the variable that the value gets assigned to in the ConnectionClass object. Then, look at where that is used. The problem is /probably/ in qresult.c, connection.c (not the #ifndef USE_LIBPQ bits), or, if you're really unlucky, copy_and_convert_field in convert.c Good luck, and be sure to let someone know what you're doing so they can send dogs when you don't come back... /D -----Original Message----- From: "Joel Fradkin"<jfradkin@wazagua.com> Sent: 31/08/05 20:07:46 To: "pgsql-odbc@postgresql.org"<pgsql-odbc@postgresql.org> Subject: [ODBC] figuring out why I am having this issue I do not mind researching the text field problem myself, but looking at the source code I have no idea where to look or how to approach this. I have seen a few email where some of the developers talked about how they were getting feed back, but to be honest never paid much attention. I can look in the archive (and probably will), but if any of you who has worked on the code could maybe point me in the right direction like which .c file would be looking at MaxLongVarcharSize I did a search and only saw it referenced in one file and it does not look to me like it is doing anything with text fields, so I must be missing something. Any ideas would be a big help. Joel Fradkin -----Unmodified Original Message----- I do not mind researching the text field problem myself, but looking at the source code I have no idea where to look or how to approach this. I have seen a few email where some of the developers talked about how they were getting feed back, but to be honest never paid much attention. I can look in the archive (and probably will), but if any of you who has worked on the code could maybe point me in the right direction like which .c file would be looking at MaxLongVarcharSize I did a search and only saw it referenced in one file and it does not look to me like it is doing anything with text fields, so I must be missing something. Any ideas would be a big help. Joel Fradkin
Joel, The problem is not that we won't help, but mainly I suspect we're in timezones some way east of you. For example, I'm watchingtelly, eating a popadom, and thinking about having a beer and going to bed!! (I'm also on my pda, and don't havethe source right now). A hint though - look in the connectionstring in mylog, and find the actual option name/code. Then, look in options.c (iirc),and see if you can figure out the variable that the value gets assigned to in the ConnectionClass object. Then, lookat where that is used. The problem is /probably/ in qresult.c, connection.c (not the #ifndef USE_LIBPQ bits), or, ifyou're really unlucky, copy_and_convert_field in convert.c Good luck, and be sure to let someone know what you're doing so they can send dogs when you don't come back... /D -----Original Message----- From: "Joel Fradkin"<jfradkin@wazagua.com> Sent: 31/08/05 20:07:46 To: "pgsql-odbc@postgresql.org"<pgsql-odbc@postgresql.org> Subject: [ODBC] figuring out why I am having this issue I do not mind researching the text field problem myself, but looking at the source code I have no idea where to look or how to approach this. I have seen a few email where some of the developers talked about how they were getting feed back, but to be honest never paid much attention. I can look in the archive (and probably will), but if any of you who has worked on the code could maybe point me in the right direction like which .c file would be looking at MaxLongVarcharSize I did a search and only saw it referenced in one file and it does not look to me like it is doing anything with text fields, so I must be missing something. Any ideas would be a big help. Joel Fradkin -----Unmodified Original Message----- I do not mind researching the text field problem myself, but looking at the source code I have no idea where to look or how to approach this. I have seen a few email where some of the developers talked about how they were getting feed back, but to be honest never paid much attention. I can look in the archive (and probably will), but if any of you who has worked on the code could maybe point me in the right direction like which .c file would be looking at MaxLongVarcharSize I did a search and only saw it referenced in one file and it does not look to me like it is doing anything with text fields, so I must be missing something. Any ideas would be a big help. Joel Fradkin
I did try looking at it a bit and did not resolve the issue.
I used a snapshot build (was a few days older then my build) and it did not
seem to have any issue with the specific text field, but the asp page was
not formatting correctly, so maybe it was doing something else.
I also tried setting TextAsLongVarchar=0
Which worked on my development box running XP pro, but did not work in
production running win2k.
I will look more tomorrow, but I could not even see what the variable was
being set to, to look at the other modules.
In my log file I could only see references to it :
MaxLongVarcharSize=16280;
Looking for the value 16280 I could see :
Just now cutting this out I thought it was weird that it says
B1 = 8k in one line (the line that mentions maxvarcharlength and in another
line it has B1=16k?
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'MaxVarcharSize', value = '254'
And
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_;attribute = 'TextAsLongVarchar', value = '1'
our_connect_string =
'DRIVER={PostgreSQL};UID=postgres;PWD=xxxxxx;DATABASE=wazagua;SERVER=192.168
.123.121;PORT=5432;ReadOnly=0;Protocol=6.4;FakeOidIndex=0;ShowOidColumn=0;Ro
wVersioning=0;ShowSystemTables=0;ConnSettings=;Fetch=100;Socket=4096;Unknown
Sizes=0;MaxVarcharSize=254;MaxLongVarcharSize=16280;Debug=1;CommLog=0;Optimi
zer=1;Ksqo=1;UseDeclareFetch=0;TextAsLongVarchar=1;UnknownsAsLongVarchar=0;B
oolsAsChar=1;Parse=0;CancelAsFreeStmt=0;ExtraSysTablePrefixes=dd_;LFConversi
on=1;UpdatableCursors=1;DisallowPremature=0;TrueIsMinus1=0;BI=0;ByteaAsLongV
arBinary=0;UseServerSidePrepare=0;'
attribute = 'DRIVER', value = '{PostgreSQL}'
CopyCommonAttributes:
A7=100;A8=8192;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'UID', value = 'postgres'
CopyCommonAttributes:
A7=100;A8=8192;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'PWD', value = 'xxxxx'
CopyCommonAttributes:
A7=100;A8=8192;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'DATABASE', value = 'wazagua'
CopyCommonAttributes:
A7=100;A8=8192;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'SERVER', value = '192.168.123.121'
CopyCommonAttributes:
A7=100;A8=8192;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'PORT', value = '5432'
CopyCommonAttributes:
A7=100;A8=8192;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'ReadOnly', value = '0'
CopyCommonAttributes:
A7=100;A8=8192;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'Protocol', value = '6.4'
CopyCommonAttributes:
A7=100;A8=8192;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'FakeOidIndex', value = '0'
CopyCommonAttributes:
A7=100;A8=8192;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'ShowOidColumn', value = '0'
CopyCommonAttributes:
A7=100;A8=8192;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'RowVersioning', value = '0'
CopyCommonAttributes:
A7=100;A8=8192;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'ShowSystemTables', value = '0'
CopyCommonAttributes:
A7=100;A8=8192;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'ConnSettings', value = ''
CopyCommonAttributes:
A7=100;A8=8192;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'Fetch', value = '100'
CopyCommonAttributes:
A7=100;A8=8192;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'Socket', value = '4096'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'UnknownSizes', value = '0'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'MaxVarcharSize', value = '254'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;C
0=0;C1=0;C2=dd_;attribute = 'MaxLongVarcharSize', value = '16280'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_;attribute = 'Debug', value = '1'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_;attribute = 'CommLog', value = '0'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_;attribute = 'Optimizer', value = '1'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_;attribute = 'Ksqo', value = '1'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_;attribute = 'UseDeclareFetch', value = '0'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_;attribute = 'TextAsLongVarchar', value = '1'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_;attribute = 'UnknownsAsLongVarchar', value = '0'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_;attribute = 'BoolsAsChar', value = '1'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_;attribute = 'Parse', value = '0'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_;attribute = 'CancelAsFreeStmt', value = '0'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_;attribute = 'ExtraSysTablePrefixes', value = 'dd_'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_attribute = 'LFConversion', value = '1'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_attribute = 'UpdatableCursors', value = '1'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_attribute = 'DisallowPremature', value = '0'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_attribute = 'TrueIsMinus1', value = '0'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_attribute = 'BI', value = '0'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_attribute = 'ByteaAsLongVarBinary', value = '0'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_attribute = 'UseServerSidePrepare', value = '0'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=16280;B2=1;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;
C0=0;C1=0;C2=dd_CC_connect: entering...
CC_connect(): DSN = '', server = '192.168.123.121', port = '5432', sslmode =
'prefer' database = 'wazagua', username = 'postgres', password='xxxxx'
Joel Fradkin
Wazagua, Inc.
2520 Trailmate Dr
Sarasota, Florida 34243
Tel. 941-753-7111 ext 305
jfradkin@wazagua.com
www.wazagua.com
Powered by Wazagua
Providing you with the latest Web-based technology & advanced tools.
C 2004. WAZAGUA, Inc. All rights reserved. WAZAGUA, Inc
This email message is for the use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and delete and destroy
all copies of the original message, including attachments.
-----Original Message-----
From: pgsql-odbc-owner@postgresql.org
[mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Dave Page
Sent: Wednesday, August 31, 2005 3:34 PM
To: jfradkin@wazagua.com; pgsql-odbc@postgresql.org
Subject: Re: [ODBC] figuring out why I am having this issue
Joel,
The problem is not that we won't help, but mainly I suspect we're in
timezones some way east of you. For example, I'm watching telly, eating a
popadom, and thinking about having a beer and going to bed!! (I'm also on my
pda, and don't have the source right now).
A hint though - look in the connectionstring in mylog, and find the actual
option name/code. Then, look in options.c (iirc), and see if you can figure
out the variable that the value gets assigned to in the ConnectionClass
object. Then, look at where that is used. The problem is /probably/ in
qresult.c, connection.c (not the #ifndef USE_LIBPQ bits), or, if you're
really unlucky, copy_and_convert_field in convert.c
Good luck, and be sure to let someone know what you're doing so they can
send dogs when you don't come back...
/D
-----Original Message-----
From: "Joel Fradkin"<jfradkin@wazagua.com>
Sent: 31/08/05 20:07:46
To: "pgsql-odbc@postgresql.org"<pgsql-odbc@postgresql.org>
Subject: [ODBC] figuring out why I am having this issue
I do not mind researching the text field problem myself, but looking at the
source code I have no idea where to look or how to approach this.
I have seen a few email where some of the developers talked about how they
were getting feed back, but to be honest never paid much attention.
I can look in the archive (and probably will), but if any of you who has
worked on the code could maybe point me in the right direction like which .c
file would be looking at
MaxLongVarcharSize I did a search and only saw it referenced in one file and
it does not look to me like it is doing anything with text fields, so I must
be missing something.
Any ideas would be a big help.
Joel Fradkin
-----Unmodified Original Message-----
I do not mind researching the text field problem myself, but looking at the
source code I have no idea where to look or how to approach this.
I have seen a few email where some of the developers talked about how they
were getting feed back, but to be honest never paid much attention.
I can look in the archive (and probably will), but if any of you who has
worked on the code could maybe point me in the right direction like which .c
file would be looking at
MaxLongVarcharSize I did a search and only saw it referenced in one file and
it does not look to me like it is doing anything with text fields, so I must
be missing something.
Any ideas would be a big help.
Joel Fradkin
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
> -----Original Message-----
> From: Joel Fradkin [mailto:jfradkin@wazagua.com]
> Sent: 01 September 2005 14:48
> To: Dave Page
> Subject: RE: [ODBC] figuring out why I am having this issue
>
> What if the
> size it thinks the field is is wrong?
It defaults the max_longvarchar_size if the DB doesn't return a value.
Note that this is for the column though, not the individual field.
I suppose what could be happening is this:
1) The app queries (using SQLDescribeCol) the results for the data type
etc.
2) The app allocates a buffer based on the size reported for the notes
column.
3) The app reads a notes field (using SQLGetData), which reports the
actual field size.
4) It keeps reading chunks of data until it gets to the end, and
somewhere along the line, overflows the buffer allocated, eg:
char szData[max_longvarchar_size];
char szChunk[1024];
// Get the data in chunks
do
{
retcode = SQLGetData(hStmt, 1, SQL_C_CHAR, szChunk,
sizeof(szChunk), &cbData);
strcat(szData, szChunk);
} while (retcode != SQL_SUCCESS && retcode != SQL_NO_DATA);
> This is not an issue for all data in my table (I have a huge amount of
> records it works fine for). I noticed this notes field is
> using some odd
> char like the 1/2 char you know where it makes it small etc.
> Maybe it is not
> calculating the size of this particular note field.
I doubt it - for strings that's handled here:
void
set_tuplefield_string(TupleField *tuple_field, const char *string)
{
tuple_field->len = strlen(string);
tuple_field->value = malloc(strlen(string) + 1);
strcpy(tuple_field->value, string);
}
Regards, Dave
> -----Original Message----- > From: Joel Fradkin [mailto:jfradkin@wazagua.com] > Sent: 01 September 2005 00:28 > To: Dave Page; pgsql-odbc@postgresql.org > Subject: RE: [ODBC] figuring out why I am having this issue > > I did try looking at it a bit and did not resolve the issue. > I used a snapshot build (was a few days older then my build) > and it did not > seem to have any issue with the specific text field, but the > asp page was > not formatting correctly, so maybe it was doing something else. See, told you it was late where I was :-) It eventually gets into ConnectionClass->ConnInfo->drivers.text_as_longvarchar. The actual value names used in ini files, the registry or conn strings is MaxLongVarcharSize, or B1 for short in conn strings. > I also tried setting TextAsLongVarchar=0 > Which worked on my development box running XP pro, but did not work in > production running win2k. > > I will look more tomorrow, but I could not even see what the > variable was > being set to, to look at the other modules. > In my log file I could only see references to it : > MaxLongVarcharSize=16280; From what I can see, it's really only used for two things - 1) as the default size for fields for which the DB doesn't report a length (see around line 3337 in connection.c - might be a little out as I've been playing), 2) as the size returned as the standard for certain data types (see pgtypes.c). I really need to see a more detailed mylog to try to figure this out - unless you can see from it what function the E_FAIL occurs in? (it's usually the first part of the mylog line, after the number in brackets, and before the : Regards, Dave
I would like to look at this code, but searching the source I am not even
seeing it?
char szData[max_longvarchar_size];
char szChunk[1024];
// Get the data in chunks
do
{
retcode = SQLGetData(hStmt, 1, SQL_C_CHAR, szChunk,
sizeof(szChunk), &cbData);
strcat(szData, szChunk);
} while (retcode != SQL_SUCCESS && retcode != SQL_NO_DATA);
Maybe I am too out of touch with C to be any help, but I should at a minimum
be able to see the code you are referenceing?
Joel Fradkin
-----Original Message-----
From: Dave Page [mailto:dpage@vale-housing.co.uk]
Sent: Thursday, September 01, 2005 10:06 AM
To: Joel Fradkin
Cc: pgsql-odbc@postgresql.org
Subject: RE: [ODBC] figuring out why I am having this issue
> -----Original Message-----
> From: Joel Fradkin [mailto:jfradkin@wazagua.com]
> Sent: 01 September 2005 14:48
> To: Dave Page
> Subject: RE: [ODBC] figuring out why I am having this issue
>
> What if the
> size it thinks the field is is wrong?
It defaults the max_longvarchar_size if the DB doesn't return a value.
Note that this is for the column though, not the individual field.
I suppose what could be happening is this:
1) The app queries (using SQLDescribeCol) the results for the data type
etc.
2) The app allocates a buffer based on the size reported for the notes
column.
3) The app reads a notes field (using SQLGetData), which reports the
actual field size.
4) It keeps reading chunks of data until it gets to the end, and
somewhere along the line, overflows the buffer allocated, eg:
char szData[max_longvarchar_size];
char szChunk[1024];
// Get the data in chunks
do
{
retcode = SQLGetData(hStmt, 1, SQL_C_CHAR, szChunk,
sizeof(szChunk), &cbData);
strcat(szData, szChunk);
} while (retcode != SQL_SUCCESS && retcode != SQL_NO_DATA);
> This is not an issue for all data in my table (I have a huge amount of
> records it works fine for). I noticed this notes field is
> using some odd
> char like the 1/2 char you know where it makes it small etc.
> Maybe it is not
> calculating the size of this particular note field.
I doubt it - for strings that's handled here:
void
set_tuplefield_string(TupleField *tuple_field, const char *string)
{
tuple_field->len = strlen(string);
tuple_field->value = malloc(strlen(string) + 1);
strcpy(tuple_field->value, string);
}
Regards, Dave
> -----Original Message-----
> From: Joel Fradkin [mailto:jfradkin@wazagua.com]
> Sent: 01 September 2005 15:43
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: RE: [ODBC] figuring out why I am having this issue
>
> I would like to look at this code, but searching the source I
> am not even
> seeing it?
>
> char szData[max_longvarchar_size];
> char szChunk[1024];
>
> // Get the data in chunks
> do
> {
> retcode = SQLGetData(hStmt, 1, SQL_C_CHAR, szChunk,
> sizeof(szChunk), &cbData);
> strcat(szData, szChunk);
>
> } while (retcode != SQL_SUCCESS && retcode != SQL_NO_DATA);
>
> Maybe I am too out of touch with C to be any help, but I
> should at a minimum
> be able to see the code you are referenceing?
:-)
You won't find that in the source - it's an example to show what your
app (or MS ADO or similar) might be doing wrong. If the actual data
being read in the SQLGetData call is larger than max_longvarchar_size,
it'll overflow szData.
I guess one answer might be to cap the size reported by SQLGetData to
whatever the column size is, but I'm pretty sure that will likely break
things for other people (though it should be fixable by tweaking
maxlongvarcharsize).
Regards, Dave.
I don't get that kind of control.
In asp you assign a record set:
set rec = cmd.Execute
Rec is not defined other then
set rec = server.CreateObject("ADODB.Recordset")
What is weird is one SQL from this record where works and another does not.
One is for our print preview page and it has several fields de-normalized
for display (it works), while the other is just reading from the table using
a normalized data set. Why changing max changes it to working is not clear
as it should be able to determine the size of the field, and why changing it
breaks other places (I am making it larger so it shouldn't be causing
e_failed).
Joel Fradkin
Wazagua, Inc.
2520 Trailmate Dr
Sarasota, Florida 34243
Tel. 941-753-7111 ext 305
jfradkin@wazagua.com
www.wazagua.com
Powered by Wazagua
Providing you with the latest Web-based technology & advanced tools.
C 2004. WAZAGUA, Inc. All rights reserved. WAZAGUA, Inc
This email message is for the use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and delete and destroy
all copies of the original message, including attachments.
-----Original Message-----
From: Dave Page [mailto:dpage@vale-housing.co.uk]
Sent: Thursday, September 01, 2005 10:50 AM
To: Joel Fradkin
Cc: pgsql-odbc@postgresql.org
Subject: RE: [ODBC] figuring out why I am having this issue
> -----Original Message-----
> From: Joel Fradkin [mailto:jfradkin@wazagua.com]
> Sent: 01 September 2005 15:43
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: RE: [ODBC] figuring out why I am having this issue
>
> I would like to look at this code, but searching the source I
> am not even
> seeing it?
>
> char szData[max_longvarchar_size];
> char szChunk[1024];
>
> // Get the data in chunks
> do
> {
> retcode = SQLGetData(hStmt, 1, SQL_C_CHAR, szChunk,
> sizeof(szChunk), &cbData);
> strcat(szData, szChunk);
>
> } while (retcode != SQL_SUCCESS && retcode != SQL_NO_DATA);
>
> Maybe I am too out of touch with C to be any help, but I
> should at a minimum
> be able to see the code you are referenceing?
:-)
You won't find that in the source - it's an example to show what your
app (or MS ADO or similar) might be doing wrong. If the actual data
being read in the SQLGetData call is larger than max_longvarchar_size,
it'll overflow szData.
I guess one answer might be to cap the size reported by SQLGetData to
whatever the column size is, but I'm pretty sure that will likely break
things for other people (though it should be fixable by tweaking
maxlongvarcharsize).
Regards, Dave.
That is the error description
If con.Errors.Count >= 1 Then
set Error = con.Errors.Item(0)
'take the error code from SQL Server
ErrCode = Error.NativeError
response.Write(cstr(Error.Description))
Response.End
End If
Could be there is better method, but this what I have been using.
I have tested putting a 300 meg text field in the data base nad it worked so
not clear why it works on most data and this one does not.
I did email you the log file (not sure it is any help).
Joel Fradkin
Wazagua, Inc.
2520 Trailmate Dr
Sarasota, Florida 34243
Tel. 941-753-7111 ext 305
jfradkin@wazagua.com
www.wazagua.com
Powered by Wazagua
Providing you with the latest Web-based technology & advanced tools.
C 2004. WAZAGUA, Inc. All rights reserved. WAZAGUA, Inc
This email message is for the use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and delete and destroy
all copies of the original message, including attachments.
-----Original Message-----
From: Dave Page [mailto:dpage@vale-housing.co.uk]
Sent: Thursday, September 01, 2005 11:07 AM
To: Joel Fradkin
Cc: pgsql-odbc@postgresql.org
Subject: RE: [ODBC] figuring out why I am having this issue
> -----Original Message-----
> From: Joel Fradkin [mailto:jfradkin@wazagua.com]
> Sent: 01 September 2005 16:00
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: RE: [ODBC] figuring out why I am having this issue
>
> I don't get that kind of control.
>
> In asp you assign a record set:
> set rec = cmd.Execute
>
> Rec is not defined other then
> set rec = server.CreateObject("ADODB.Recordset")
Yeah, I know - I think you miss my point though. If for some reason the
DB doesn't tell us the size of the column (because it's a text field for
example), we default to max_lvc. If the data is longer than that though,
ADO might overflow an allocated buffer. I would hope Microsoft wrote it
better than than, but it's the best I've got right now!!
> What is weird is one SQL from this record where works and
> another does not.
Which kinda throws the size issue out the window. You sure this is
caused by ODBC? Can't ASP be more verbose than E_FAILED?
/D
> -----Original Message-----
> From: Joel Fradkin [mailto:jfradkin@wazagua.com]
> Sent: 01 September 2005 16:00
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: RE: [ODBC] figuring out why I am having this issue
>
> I don't get that kind of control.
>
> In asp you assign a record set:
> set rec = cmd.Execute
>
> Rec is not defined other then
> set rec = server.CreateObject("ADODB.Recordset")
Yeah, I know - I think you miss my point though. If for some reason the
DB doesn't tell us the size of the column (because it's a text field for
example), we default to max_lvc. If the data is longer than that though,
ADO might overflow an allocated buffer. I would hope Microsoft wrote it
better than than, but it's the best I've got right now!!
> What is weird is one SQL from this record where works and
> another does not.
Which kinda throws the size issue out the window. You sure this is
caused by ODBC? Can't ASP be more verbose than E_FAILED?
/D
> -----Original Message-----
> From: Joel Fradkin [mailto:jfradkin@wazagua.com]
> Sent: 01 September 2005 16:16
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: RE: [ODBC] figuring out why I am having this issue
>
> That is the error description
> If con.Errors.Count >= 1 Then
> set Error = con.Errors.Item(0)
> 'take the error code from SQL Server
> ErrCode = Error.NativeError
> response.Write(cstr(Error.Description))
> Response.End
> End If
>
> Could be there is better method, but this what I have been using.
Dunno if there's a better method - I would be inclined to loop round
con.Errors.Count though - maybe something like:
For X = 1 To con.Errors.Count
set Error = con.Errors.Item(X - 1)
'take the error code from SQL Server
ErrCode = Error.NativeError
response.Write(cstr(Error.Description))
End If
Response.End
> I have tested putting a 300 meg text field in the data base
> nad it worked so
> not clear why it works on most data and this one does not.
> I did email you the log file (not sure it is any help).
Yeah, I can't see anything obviously wrong in it. A few things to
consider though:
- ASP seems to be retrieving data as SQL_C_CHAR, which means it's
getting raw data, not UCS2 converted from UTF8.
- ASP is retrieving data in 32KB chunks, so it would probably be worth
making sure max_long_varchar is at least that.
- Some data (quotes and such) doesn't look so good. Could it have been
pasted from MS Word or similar?
- Are you compiling the driver yourself? If so how? It seems to be using
the old comms layer, not libpq (which I'm no longer working on). The
giveaway is lines like the following which are for debugging the network
protocol:
connecting to the server socket...
connection to the server socket succeeded.
sizeof startup packet = 292
sent the authentication block.
sent the authentication block successfully.
gonna do authentication
read 15, global_socket_buffersize=8192
auth got 'R'
areq = 0
auth got 'K'
auth got 'Z'
All this is now encapsulated in libpq, which doesn't log what it's
doing.
To fix this, compile on the command line:
nmake /f win32.mak
This should ensure you get the default libpq build. If you're doing this
in an IDE, make sure USE_LIBPQ is defined!
Regards, Dave.
Yea I did actually wrap the error as you suggested because I was not getting
anything back from the routine.
Te e_failed was from internet explorer not my app (I did not have on error
resume statement).
When I put the statement it still saw an error in error count, but no
description not even an e_failed?
Joel Fradkin
-----Original Message-----
From: Dave Page [mailto:dpage@vale-housing.co.uk]
Sent: Thursday, September 01, 2005 12:14 PM
To: Joel Fradkin
Cc: pgsql-odbc@postgresql.org
Subject: RE: [ODBC] figuring out why I am having this issue
> -----Original Message-----
> From: Joel Fradkin [mailto:jfradkin@wazagua.com]
> Sent: 01 September 2005 16:16
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: RE: [ODBC] figuring out why I am having this issue
>
> That is the error description
> If con.Errors.Count >= 1 Then
> set Error = con.Errors.Item(0)
> 'take the error code from SQL Server
> ErrCode = Error.NativeError
> response.Write(cstr(Error.Description))
> Response.End
> End If
>
> Could be there is better method, but this what I have been using.
Dunno if there's a better method - I would be inclined to loop round
con.Errors.Count though - maybe something like:
For X = 1 To con.Errors.Count
set Error = con.Errors.Item(X - 1)
'take the error code from SQL Server
ErrCode = Error.NativeError
response.Write(cstr(Error.Description))
End If
Response.End
> I have tested putting a 300 meg text field in the data base
> nad it worked so
> not clear why it works on most data and this one does not.
> I did email you the log file (not sure it is any help).
Yeah, I can't see anything obviously wrong in it. A few things to
consider though:
- ASP seems to be retrieving data as SQL_C_CHAR, which means it's
getting raw data, not UCS2 converted from UTF8.
- ASP is retrieving data in 32KB chunks, so it would probably be worth
making sure max_long_varchar is at least that.
- Some data (quotes and such) doesn't look so good. Could it have been
pasted from MS Word or similar?
- Are you compiling the driver yourself? If so how? It seems to be using
the old comms layer, not libpq (which I'm no longer working on). The
giveaway is lines like the following which are for debugging the network
protocol:
connecting to the server socket...
connection to the server socket succeeded.
sizeof startup packet = 292
sent the authentication block.
sent the authentication block successfully.
gonna do authentication
read 15, global_socket_buffersize=8192
auth got 'R'
areq = 0
auth got 'K'
auth got 'Z'
All this is now encapsulated in libpq, which doesn't log what it's
doing.
To fix this, compile on the command line:
nmake /f win32.mak
This should ensure you get the default libpq build. If you're doing this
in an IDE, make sure USE_LIBPQ is defined!
Regards, Dave.
So I am not even using libpq (figures).
Seemed to be working ok until this issue with the data.
I do not have control over what they store, I can modify single quotes to ''
and such.
I am using .net project where would I define USE_LIBPQ?
Joel Fradkin
-----Original Message-----
From: Dave Page [mailto:dpage@vale-housing.co.uk]
Sent: Thursday, September 01, 2005 12:14 PM
To: Joel Fradkin
Cc: pgsql-odbc@postgresql.org
Subject: RE: [ODBC] figuring out why I am having this issue
> -----Original Message-----
> From: Joel Fradkin [mailto:jfradkin@wazagua.com]
> Sent: 01 September 2005 16:16
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: RE: [ODBC] figuring out why I am having this issue
>
> That is the error description
> If con.Errors.Count >= 1 Then
> set Error = con.Errors.Item(0)
> 'take the error code from SQL Server
> ErrCode = Error.NativeError
> response.Write(cstr(Error.Description))
> Response.End
> End If
>
> Could be there is better method, but this what I have been using.
Dunno if there's a better method - I would be inclined to loop round
con.Errors.Count though - maybe something like:
For X = 1 To con.Errors.Count
set Error = con.Errors.Item(X - 1)
'take the error code from SQL Server
ErrCode = Error.NativeError
response.Write(cstr(Error.Description))
End If
Response.End
> I have tested putting a 300 meg text field in the data base
> nad it worked so
> not clear why it works on most data and this one does not.
> I did email you the log file (not sure it is any help).
Yeah, I can't see anything obviously wrong in it. A few things to
consider though:
- ASP seems to be retrieving data as SQL_C_CHAR, which means it's
getting raw data, not UCS2 converted from UTF8.
- ASP is retrieving data in 32KB chunks, so it would probably be worth
making sure max_long_varchar is at least that.
- Some data (quotes and such) doesn't look so good. Could it have been
pasted from MS Word or similar?
- Are you compiling the driver yourself? If so how? It seems to be using
the old comms layer, not libpq (which I'm no longer working on). The
giveaway is lines like the following which are for debugging the network
protocol:
connecting to the server socket...
connection to the server socket succeeded.
sizeof startup packet = 292
sent the authentication block.
sent the authentication block successfully.
gonna do authentication
read 15, global_socket_buffersize=8192
auth got 'R'
areq = 0
auth got 'K'
auth got 'Z'
All this is now encapsulated in libpq, which doesn't log what it's
doing.
To fix this, compile on the command line:
nmake /f win32.mak
This should ensure you get the default libpq build. If you're doing this
in an IDE, make sure USE_LIBPQ is defined!
Regards, Dave.
Thanks Greg.
I inherited this app and doing a one stop shop for db would be an excellent
idea, there is stuff everywhere (no error handling until I got on board, but
I have just been sticking it where the db action is.
Unfortunately I am making no progress. I tried the snapshot using the
connection DRIVER={PostgreSQL-libpq} so I am more confident at least I am
testing the correct driver version.
It is cutting my text fields off at 254 chars.
I tried making
MaxVarcharSize=32768;MaxLongVarcharSize=32768;
Thinking it might be ignoring the TextAsLongVarchar=1;
But still was cutting the text off.
So basically I can not use the libpq driver at the moment, will have to
figure out why its cutting off the text.
Joel Fradkin
Wazagua, Inc.
2520 Trailmate Dr
Sarasota, Florida 34243
Tel. 941-753-7111 ext 305
jfradkin@wazagua.com
www.wazagua.com
Powered by Wazagua
Providing you with the latest Web-based technology & advanced tools.
C 2004. WAZAGUA, Inc. All rights reserved. WAZAGUA, Inc
This email message is for the use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and delete and destroy
all copies of the original message, including attachments.
-----Original Message-----
From: Greg Campbell [mailto:greg.campbell@us.michelin.com]
Sent: Thursday, September 01, 2005 2:07 PM
To: Dave Page
Cc: Joel Fradkin; pgsql-odbc@postgresql.org
Subject: Re: [ODBC] figuring out why I am having this issue
I like the collection construct (for each)
If (error.Number <> 0) Then
'and this for-next loop is usually in a handle_db_errors routine
instead of typing/pasting it all over my code
'plus it become a one-stop change where I can log the error to a db
or file or event_log.
For Each dberr in con.Errors
Response.Write "An Error occurred................." & <br> &
vbCrLf
Response.Write "Number: " & CStr(dberr.Number) & <br> &
vbCrLf
Response.Write "Source: " & dberr.Source & <br> & vbCrLf
Response.Write "NativeError: " & CStr(dberr.NativeError) &
<br> & vbCrLf
Response.Write "Description: " & dberr.Description & <br>
Next
Response.End
End If
It's all the same.
Dave Page wrote:
>
>
>
>>-----Original Message-----
>>From: Joel Fradkin [mailto:jfradkin@wazagua.com]
>>Sent: 01 September 2005 16:16
>>To: Dave Page
>>Cc: pgsql-odbc@postgresql.org
>>Subject: RE: [ODBC] figuring out why I am having this issue
>>
>>That is the error description
>>If con.Errors.Count >= 1 Then
>> set Error = con.Errors.Item(0)
>> 'take the error code from SQL Server
>> ErrCode = Error.NativeError
>> response.Write(cstr(Error.Description))
>> Response.End
>>End If
>>
>>Could be there is better method, but this what I have been using.
>
>
> Dunno if there's a better method - I would be inclined to loop round
> con.Errors.Count though - maybe something like:
>
> For X = 1 To con.Errors.Count
> set Error = con.Errors.Item(X - 1)
> 'take the error code from SQL Server
> ErrCode = Error.NativeError
> response.Write(cstr(Error.Description))
> End If
> Response.End
>
>
>
>
>>I have tested putting a 300 meg text field in the data base
>>nad it worked so
>>not clear why it works on most data and this one does not.
>>I did email you the log file (not sure it is any help).
>
>
> Yeah, I can't see anything obviously wrong in it. A few things to
> consider though:
>
> - ASP seems to be retrieving data as SQL_C_CHAR, which means it's
> getting raw data, not UCS2 converted from UTF8.
>
> - ASP is retrieving data in 32KB chunks, so it would probably be worth
> making sure max_long_varchar is at least that.
>
> - Some data (quotes and such) doesn't look so good. Could it have been
> pasted from MS Word or similar?
>
> - Are you compiling the driver yourself? If so how? It seems to be using
> the old comms layer, not libpq (which I'm no longer working on). The
> giveaway is lines like the following which are for debugging the network
> protocol:
>
> connecting to the server socket...
> connection to the server socket succeeded.
> sizeof startup packet = 292
> sent the authentication block.
> sent the authentication block successfully.
> gonna do authentication
> read 15, global_socket_buffersize=8192
> auth got 'R'
> areq = 0
> auth got 'K'
> auth got 'Z'
>
> All this is now encapsulated in libpq, which doesn't log what it's
> doing.
>
> To fix this, compile on the command line:
>
> nmake /f win32.mak
>
> This should ensure you get the default libpq build. If you're doing this
> in an IDE, make sure USE_LIBPQ is defined!
>
> Regards, Dave.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
I like the collection construct (for each)
If (error.Number <> 0) Then
'and this for-next loop is usually in a handle_db_errors routine instead of typing/pasting it all over my code
'plus it become a one-stop change where I can log the error to a db or file or event_log.
For Each dberr in con.Errors
Response.Write "An Error occurred................." & <br> & vbCrLf
Response.Write "Number: " & CStr(dberr.Number) & <br> & vbCrLf
Response.Write "Source: " & dberr.Source & <br> & vbCrLf
Response.Write "NativeError: " & CStr(dberr.NativeError) & <br> & vbCrLf
Response.Write "Description: " & dberr.Description & <br>
Next
Response.End
End If
It's all the same.
Dave Page wrote:
>
>
>
>>-----Original Message-----
>>From: Joel Fradkin [mailto:jfradkin@wazagua.com]
>>Sent: 01 September 2005 16:16
>>To: Dave Page
>>Cc: pgsql-odbc@postgresql.org
>>Subject: RE: [ODBC] figuring out why I am having this issue
>>
>>That is the error description
>>If con.Errors.Count >= 1 Then
>> set Error = con.Errors.Item(0)
>> 'take the error code from SQL Server
>> ErrCode = Error.NativeError
>> response.Write(cstr(Error.Description))
>> Response.End
>>End If
>>
>>Could be there is better method, but this what I have been using.
>
>
> Dunno if there's a better method - I would be inclined to loop round
> con.Errors.Count though - maybe something like:
>
> For X = 1 To con.Errors.Count
> set Error = con.Errors.Item(X - 1)
> 'take the error code from SQL Server
> ErrCode = Error.NativeError
> response.Write(cstr(Error.Description))
> End If
> Response.End
>
>
>
>
>>I have tested putting a 300 meg text field in the data base
>>nad it worked so
>>not clear why it works on most data and this one does not.
>>I did email you the log file (not sure it is any help).
>
>
> Yeah, I can't see anything obviously wrong in it. A few things to
> consider though:
>
> - ASP seems to be retrieving data as SQL_C_CHAR, which means it's
> getting raw data, not UCS2 converted from UTF8.
>
> - ASP is retrieving data in 32KB chunks, so it would probably be worth
> making sure max_long_varchar is at least that.
>
> - Some data (quotes and such) doesn't look so good. Could it have been
> pasted from MS Word or similar?
>
> - Are you compiling the driver yourself? If so how? It seems to be using
> the old comms layer, not libpq (which I'm no longer working on). The
> giveaway is lines like the following which are for debugging the network
> protocol:
>
> connecting to the server socket...
> connection to the server socket succeeded.
> sizeof startup packet = 292
> sent the authentication block.
> sent the authentication block successfully.
> gonna do authentication
> read 15, global_socket_buffersize=8192
> auth got 'R'
> areq = 0
> auth got 'K'
> auth got 'Z'
>
> All this is now encapsulated in libpq, which doesn't log what it's
> doing.
>
> To fix this, compile on the command line:
>
> nmake /f win32.mak
>
> This should ensure you get the default libpq build. If you're doing this
> in an IDE, make sure USE_LIBPQ is defined!
>
> Regards, Dave.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
Attachment
Joel Fradkin
I found the h file in the postgres source and included in my build path, but
many errors.
d:\joel\wazagua_src\psqlodbc\socket.c(62): error C2037: left of 'connInfo'
specifies undefined struct/union 'ConnectionClass_'
d:\joel\wazagua_src\psqlodbc\lobj.c(23): error C2061: syntax error :
identifier 'lo_creat'
d:\joel\wazagua_src\psqlodbc\lobj.c(23): error C2059: syntax error : ';'
d:\joel\wazagua_src\psqlodbc\lobj.c(23): error C2059: syntax error : 'type'
d:\joel\wazagua_src\psqlodbc\lobj.c(55): warning C4013: 'CC_send_function'
undefined; assuming extern returning int
d:\joel\wazagua_src\psqlodbc\lobj.c(58): warning C4013: 'lo_lseek'
undefined; assuming extern returning int
d:\joel\wazagua_src\psqlodbc\lobj.c(174): error C2146: syntax error :
missing ')' before identifier 'lobjId'
d:\joel\wazagua_src\psqlodbc\lobj.c(174): error C2144: syntax error :
'<Unknown>' should be preceded by '<Unknown>'
d:\joel\wazagua_src\psqlodbc\lobj.c(174): error C2144: syntax error :
'<Unknown>' should be preceded by '<Unknown>'
d:\joel\wazagua_src\psqlodbc\lobj.c(174): error C2143: syntax error :
missing ')' before 'identifier'
d:\joel\wazagua_src\psqlodbc\lobj.c(174): error C2081: 'Oid' : name in
formal parameter list illegal
d:\joel\wazagua_src\psqlodbc\lobj.c(174): error C2061: syntax error :
identifier 'lobjId'
d:\joel\wazagua_src\psqlodbc\lobj.c(174): error C2059: syntax error : ';'
d:\joel\wazagua_src\psqlodbc\lobj.c(174): error C2059: syntax error : ')'
d:\joel\wazagua_src\psqlodbc\lobj.c(175): error C2449: found '{' at file
scope (missing function header?)
d:\joel\wazagua_src\psqlodbc\lobj.c(188): error C2059: syntax error : '}'
d:\joel\wazagua_src\psqlodbc\info30.c(20): error C2065: 'ConnInfo' :
undeclared identifier
d:\joel\wazagua_src\psqlodbc\info30.c(20): error C2065: 'ci' : undeclared
identifier
d:\joel\wazagua_src\psqlodbc\info30.c(20): error C2037: left of 'connInfo'
specifies undefined struct/union 'ConnectionClass_'
d:\joel\wazagua_src\psqlodbc\info30.c(21): error C2143: syntax error :
missing ';' before 'type'
d:\joel\wazagua_src\psqlodbc\info30.c(22): error C2143: syntax error :
missing ';' before 'type'
d:\joel\wazagua_src\psqlodbc\info30.c(24): error C2275: 'RETCODE' : illegal
use of this type as an expression
c:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\PlatformSDK\Include\sqltypes.h(134) : see declaration of 'RETCODE'
d:\joel\wazagua_src\psqlodbc\info30.c(24): error C2146: syntax error :
missing ';' before identifier 'result'
d:\joel\wazagua_src\psqlodbc\info30.c(24): error C2144: syntax error :
'<Unknown>' should be preceded by '<Unknown>'
d:\joel\wazagua_src\psqlodbc\info30.c(24): error C2144: syntax error :
'<Unknown>' should be preceded by '<Unknown>'
d:\joel\wazagua_src\psqlodbc\info30.c(24): error C2143: syntax error :
missing ';' before 'identifier'
d:\joel\wazagua_src\psqlodbc\info30.c(24): error C2065: 'result' :
undeclared identifier
d:\joel\wazagua_src\psqlodbc\info30.c(29): error C2065: 'len' : undeclared
identifier
d:\joel\wazagua_src\psqlodbc\info30.c(30): error C2065: 'value' : undeclared
identifier
d:\joel\wazagua_src\psqlodbc\info30.c(51): error C2223: left of
'->updatable_cursors' must point to struct/union
d:\joel\wazagua_src\psqlodbc\info30.c(51): error C2223: left of '->drivers'
must point to struct/union
d:\joel\wazagua_src\psqlodbc\info30.c(58): error C2223: left of '->drivers'
must point to struct/union
d:\joel\wazagua_src\psqlodbc\info30.c(69): error C2223: left of
'->updatable_cursors' must point to struct/union
d:\joel\wazagua_src\psqlodbc\info30.c(69): error C2223: left of '->drivers'
must point to struct/union
d:\joel\wazagua_src\psqlodbc\info30.c(77): error C2223: left of '->drivers'
must point to struct/union
d:\joel\wazagua_src\psqlodbc\info30.c(98): error C2223: left of
'->updatable_cursors' must point to struct/union
d:\joel\wazagua_src\psqlodbc\info30.c(109): error C2223: left of
'->updatable_cursors' must point to struct/union
d:\joel\wazagua_src\psqlodbc\info30.c(121): error C2223: left of '->drivers'
must point to struct/union
d:\joel\wazagua_src\psqlodbc\info30.c(150): warning C4013: 'PG_VERSION_LE'
undefined; assuming extern returning int
d:\joel\wazagua_src\psqlodbc\info30.c(151): error C2065: 'p' : undeclared
identifier
d:\joel\wazagua_src\psqlodbc\info30.c(151): warning C4047: '=' : 'int'
differs in levels of indirection from 'char [2]'
d:\joel\wazagua_src\psqlodbc\info30.c(153): warning C4047: '=' : 'int'
differs in levels of indirection from 'char [2]'
d:\joel\wazagua_src\psqlodbc\info30.c(157): warning C4047: '=' : 'int'
differs in levels of indirection from 'char [1]'
d:\joel\wazagua_src\psqlodbc\info30.c(177): error C2037: left of
'schema_support' specifies undefined struct/union 'ConnectionClass_'
d:\joel\wazagua_src\psqlodbc\info30.c(186): warning C4013: 'PG_VERSION_GE'
undefined; assuming extern returning int
d:\joel\wazagua_src\psqlodbc\info30.c(209): warning C4047: '=' : 'int'
differs in levels of indirection from 'char [2]'
d:\joel\wazagua_src\psqlodbc\info30.c(229): error C2037: left of
'schema_support' specifies undefined struct/union 'ConnectionClass_'
d:\joel\wazagua_src\psqlodbc\info30.c(237): warning C4013: 'PG_VERSION_GT'
undefined; assuming extern returning int
d:\joel\wazagua_src\psqlodbc\info30.c(270): warning C4047: '=' : 'int'
differs in levels of indirection from 'char [2]'
d:\joel\wazagua_src\psqlodbc\info30.c(357): warning C4013: 'CC_set_error'
undefined; assuming extern returning int
d:\joel\wazagua_src\psqlodbc\info30.c(357): error C2065:
'CONN_NOT_IMPLEMENTED_ERROR' : undeclared identifier
d:\joel\wazagua_src\psqlodbc\info30.c(358): warning C4013: 'CC_log_error'
undefined; assuming extern returning int
d:\joel\wazagua_src\psqlodbc\info30.c(366): warning C4047: 'function' :
'const char *' differs in levels of indirection from 'int'
d:\joel\wazagua_src\psqlodbc\info30.c(373): error C2037: left of 'unicode'
specifies undefined struct/union 'ConnectionClass_'
d:\joel\wazagua_src\psqlodbc\info30.c(379): error C2037: left of 'unicode'
specifies undefined struct/union 'ConnectionClass_'
d:\joel\wazagua_src\psqlodbc\info30.c(380): warning C4047: 'function' :
'const char *' differs in levels of indirection from 'int'
d:\joel\wazagua_src\psqlodbc\info30.c(382): warning C4047: 'function' :
'const char *' differs in levels of indirection from 'int'
d:\joel\wazagua_src\psqlodbc\info30.c(387): error C2065: 'CONN_TRUNCATED' :
undeclared identifier
d:\joel\wazagua_src\psqlodbc\info30.c(406): warning C4047: ':' : 'int'
differs in levels of indirection from 'char [7]'
>
> That is the error description
> If con.Errors.Count >= 1 Then
> set Error = con.Errors.Item(0)
> 'take the error code from SQL Server
> ErrCode = Error.NativeError
> response.Write(cstr(Error.Description))
> Response.End
> End If
>
> Could be there is better method, but this what I have been using.
Dunno if there's a better method - I would be inclined to loop round
con.Errors.Count though - maybe something like:
For X = 1 To con.Errors.Count
set Error = con.Errors.Item(X - 1)
'take the error code from SQL Server
ErrCode = Error.NativeError
response.Write(cstr(Error.Description))
End If
Response.End
> I have tested putting a 300 meg text field in the data base
> nad it worked so
> not clear why it works on most data and this one does not.
> I did email you the log file (not sure it is any help).
Yeah, I can't see anything obviously wrong in it. A few things to
consider though:
- ASP seems to be retrieving data as SQL_C_CHAR, which means it's
getting raw data, not UCS2 converted from UTF8.
- ASP is retrieving data in 32KB chunks, so it would probably be worth
making sure max_long_varchar is at least that.
- Some data (quotes and such) doesn't look so good. Could it have been
pasted from MS Word or similar?
- Are you compiling the driver yourself? If so how? It seems to be using
the old comms layer, not libpq (which I'm no longer working on). The
giveaway is lines like the following which are for debugging the network
protocol:
connecting to the server socket...
connection to the server socket succeeded.
sizeof startup packet = 292
sent the authentication block.
sent the authentication block successfully.
gonna do authentication
read 15, global_socket_buffersize=8192
auth got 'R'
areq = 0
auth got 'K'
auth got 'Z'
All this is now encapsulated in libpq, which doesn't log what it's
doing.
To fix this, compile on the command line:
nmake /f win32.mak
This should ensure you get the default libpq build. If you're doing this
in an IDE, make sure USE_LIBPQ is defined!
Regards, Dave.
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
Thanks to a bit of guidance from Dave and Merlin I now have the latest CVS source (using a CVS tool). I was able to compile via command line. I tried the latest build and the text issue did not come up (I could view and edit the text field giving me the issue). I however had host.dll give me a memory error trying to print preview, so I am looking at what might be the issue. I appreciate everyone helping me out as I know you guys are busy. I still cant believe I was using the old driver all that time (I am still using it in production, but hope I can resolve this memory blow out). Joel Fradkin
> -----Original Message----- > From: Joel Fradkin [mailto:jfradkin@wazagua.com] > Sent: 02 September 2005 15:08 > To: 'Joel Fradkin'; Dave Page > Cc: pgsql-odbc@postgresql.org > Subject: RE: [ODBC] figuring out why I am having this issue > > Thanks to a bit of guidance from Dave and Merlin I now have > the latest CVS > source (using a CVS tool). > I was able to compile via command line. > I tried the latest build and the text issue did not come up > (I could view > and edit the text field giving me the issue). > I however had host.dll give me a memory error trying to print > preview, so I > am looking at what might be the issue. Ahh, well, host.dll definitely isn't ours!! > I appreciate everyone helping me out as I know you guys are busy. > I still cant believe I was using the old driver all that time > (I am still > using it in production, but hope I can resolve this memory blow out). Hehehe. Of course, some of my unicode fixes applied to either version of the driver which is why you probably didn't notice! Glad to hear the problem's gone though. Regards, Dave.
The patch fixed the other issue (my sql was 8k so fixing connect did the trick). I manually applied the changes is there an easier way? Again I appreciate all the help, I will test more to see if any other issues come up, but at least my initial problem with the FE driver seems to not be a problem in libpq land. Joel Fradkin Wazagua, Inc. 2520 Trailmate Dr Sarasota, Florida 34243 Tel. 941-753-7111 ext 305 jfradkin@wazagua.com www.wazagua.com Powered by Wazagua Providing you with the latest Web-based technology & advanced tools. C 2004. WAZAGUA, Inc. All rights reserved. WAZAGUA, Inc This email message is for the use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and delete and destroy all copies of the original message, including attachments. -----Original Message----- From: Dave Page [mailto:dpage@vale-housing.co.uk] Sent: Friday, September 02, 2005 10:19 AM To: Joel Fradkin Cc: pgsql-odbc@postgresql.org Subject: RE: [ODBC] figuring out why I am having this issue > -----Original Message----- > From: Joel Fradkin [mailto:jfradkin@wazagua.com] > Sent: 02 September 2005 15:08 > To: 'Joel Fradkin'; Dave Page > Cc: pgsql-odbc@postgresql.org > Subject: RE: [ODBC] figuring out why I am having this issue > > Thanks to a bit of guidance from Dave and Merlin I now have > the latest CVS > source (using a CVS tool). > I was able to compile via command line. > I tried the latest build and the text issue did not come up > (I could view > and edit the text field giving me the issue). > I however had host.dll give me a memory error trying to print > preview, so I > am looking at what might be the issue. Ahh, well, host.dll definitely isn't ours!! > I appreciate everyone helping me out as I know you guys are busy. > I still cant believe I was using the old driver all that time > (I am still > using it in production, but hope I can resolve this memory blow out). Hehehe. Of course, some of my unicode fixes applied to either version of the driver which is why you probably didn't notice! Glad to hear the problem's gone though. Regards, Dave.
> -----Original Message----- > From: Joel Fradkin [mailto:jfradkin@wazagua.com] > Sent: 02 September 2005 15:44 > To: Dave Page > Cc: pgsql-odbc@postgresql.org > Subject: RE: [ODBC] figuring out why I am having this issue > > The patch fixed the other issue (my sql was 8k so fixing > connect did the > trick). > I manually applied the changes is there an easier way? Something like: patch -p0 < patch.diff I generally do that sort of thing from an Msys prompt. Or, because I've committed it to CVS, you can now just do a CVS update. > Again I appreciate all the help, I will test more to see if > any other issues > come up, but at least my initial problem with the FE driver > seems to not be > a problem in libpq land. :-) /D