What to do about errors returned by odbc

I am running 8.0.3 database with 7.4 odbc.

I am working on getting my ASCII over to Unicode so I can use the newer
odbc.

I get on a too often basis the ODBC lock up on the IIS server (I can re-boot
IIS and see ODBC come back).

The machine is not out of memory (4 gig Dell running win2k, database is on a
8 gig redhat box).

Unfortunately I display the error returned from the object and it includes
the text "Catastrophic Error".

This has been bad and I need to fix it, but I believe if I understand my
initial research it is actually an error from MS (either IIS or the ODBC
layer).

Since it does not appear to be a memory issue (last time I had it happen the
machine was at 500 meg of 2 gig used by IIS) I am looking for ideas as what
to look for.

Our application was on MSSQL and did not have errors with the odbc (servers
were very stable) to MSSQL.

I have us converted and eliminated most of the application type errors from
the conversion, but the odbc to postgres I think is our issue (may be how we
have it coded).

I am not using any kind of pooling (not sure if IIS does this on its own as
I do not see a million connections and we generally have 200+ concurrent
users).

Any ideas I can research would be greatly appreciated.

Joel Fradkin

Wazagua, Inc.
2520 Trailmate Dr
Sarasota, Florida 34243
Tel. 941-753-7111 ext 305

jfradkin(at)wazagua(dot)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.

This might be a memory issue on 32bit computers.
psqlodbc loads the whole query result into memory by default,
on Windows too.

IIS or Windows might supply memory at most 1-3 gigabytes for the CGI binary.
So the actual upper limit might actually be much less, than 4G.

This can be overcome by using ODBC directives like:

Fetch = 2048
UseDeclareFetch = 1

Regards,
Marko Ristola

Joel Fradkin wrote:

> I am running 8.0.3 database with 7.4 odbc.
>
> I am working on getting my ASCII over to Unicode so I can use the
> newer odbc.
>
> I get on a too often basis the ODBC lock up on the IIS server (I can
> re-boot IIS and see ODBC come back).
>
> The machine is not out of memory (4 gig Dell running win2k, database
> is on a 8 gig redhat box).
>
> Unfortunately I display the error returned from the object and it
> includes the text “Catastrophic Error”.
>
> This has been bad and I need to fix it, but I believe if I understand
> my initial research it is actually an error from MS (either IIS or the
> ODBC layer).
>
> Since it does not appear to be a memory issue (last time I had it
> happen the machine was at 500 meg of 2 gig used by IIS) I am looking
> for ideas as what to look for.
>
> Our application was on MSSQL and did not have errors with the odbc
> (servers were very stable) to MSSQL.
>
> I have us converted and eliminated most of the application type errors
> from the conversion, but the odbc to postgres I think is our issue
> (may be how we have it coded).
>
> I am not using any kind of pooling (not sure if IIS does this on its
> own as I do not see a million connections and we generally have 200+
> concurrent users).
>
> Any ideas I can research would be greatly appreciated.
>
> Joel Fradkin
>
> Wazagua, Inc.
> 2520 Trailmate Dr
> Sarasota, Florida 34243
> Tel. 941-753-7111 ext 305
>
> jfradkin(at)wazagua(dot)com <mailto:jfradkin(at)wazagua(dot)com>
> www.wazagua.com <http://www.wazagua.com>
> Powered by Wazagua
> Providing you with the latest Web-based technology & advanced tools.
> © 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.
>
>