We have a DBSELECT that is accessing a Microsoft Access 
table and is causing Screensurfer to crash.  It is dying on 
the TEFETCH statement.

This problem occurs on a server running Windows 2000 SP1, 
screensurfer 2.0.11F, with an ODBC driver for Microsoft 
Access, version 4.00.5303.01.  The same code/query works 
fine on my local workstation: Windows NT 4.0 Workstation 
SP6, screensurfer 2.0.11F, with an ODBC driver for 
Microsoft Access, version 3.50.3602.00.

I will email the drwtsn32.log, templates.log, and the 
siccodes.stml files to surfer@ie.com after I finish this 
ticket.

Let me know if you need any other information.

Can you also please send an export of the table design that 
the crashing select is running against?

Plus, just to cover all the bases--please confirm that 
there are no compile errors--if the files have moved and 
the DBconnection definition isn't compiled prior to the 
database select, the compile will have an error on the 
select and the fetch will crash...this can be corrected 
with a compiler list file, but this is one cause of DB 
crashes that we need to rule out.

Yes, it does compile cleanly.  All of our DBSelects are 
declared in the same file as the DBSource, and after the 
DBSource, they are using.  I also sent the access database 
via email as you requested.  One other note, the access 
database is an Access 97 file, not Access 2000.

We have made progress on this issue--have reproduced the 
crash, which is related to the use of the calculated column 
in that select.

For some reason, Access is reporting the datatype as a 
date/time/datetime (whatever) and is then reporting the 
size of the data as an extremely large integer (2 trillion 
range), which is what is causing the trap when this size is 
allocated to hold selected data.  We are looking into ODBC 
version as a possible fix, or further research into why 
this column information is so wrong (might need to just 
force it to a reasonable value for now...).

We have based the ODBC version in SS as ODBC 2.0--will look 
into upgrading to ODBC 3.0 which isn't too big a deal and 
my guess is this will fix the problem.

Further update-- in fact, the datatype is not a date one 
(that was a debugger/optimization goof).

It looks like as a calculated field, the database is just 
throwing out a very large number for the potential size of 
the target data.

The default fix is to constrain the size of a returned 
column to the Screensurfer maximum string size (which is in-
fact something that should already be in the ODBC support).

We will also try to add a statement-specific maximum string 
size, so that you don't end-up with large memory 
allocations for selects that really don't need them.

Should have a fix ready later this afternoon.

Fix has been applied and is in regression testing.

Added a new attribute to the select declare of "MaxColSize" 
which allows an override for that statement of the defined 
maximum string size.  This helps tune the memory allocation 
for the statement--for this one, you would set this to 50 
or something since the calculated column is far smaller 
than that.