odbc results in invalid access to memory location

Hello all,

I tried to connect to a (quite large) Paradox table from Dolphin 5.03
via the ODBC driver supplied with either Windows XP or Office 2k, I
don't know where exactly it originates.

With a (relatively) small table, the following expressions evaluated
just fine:

wb := DBConnection new dsn: 'winbasys'; open; yourself.
wb tables inspect.
dbrs := wb query: 'select * from blz'.
dbrs inspect.
dbrs close.

The table "blz" consists of 4 fields with a record size of 35 bytes and
5317 records, totalling at 186kB.

However, when I tried the same with a large table (233 fields, 2938
bytes/record, 3410 records, 10922kB), the display in the left pane of
the result set's inspector does not show the first entries, only the
result set itself. After evaluating the query: message, the cursor blink
rate in the workspace is about half the usual. Shortly
after closing the inspector, (presumably) every garbage collection
throws an exception until finally Dolphin crashes:

01:12:18, Montag, 28. April 2003: 'Invalid access to memory location.
Reading 0x18, IP 0x10009E5A (C:\Programme\Gemeinsame Dateien\Object
Arts\Dolphin Smalltalk 5.0\DolphinVM005.dll)'
ProcessorScheduler>>gpFault:
[] in ProcessorScheduler>>vmi:list:no:with:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>vmi:list:no:with:
SmallInteger(Object)>>primitiveFailed
SmallInteger(MemoryManager)>>primCollectGarbage:
MemoryManager>>collectGarbage
MemoryManager>>aboutToIdle
InputState>>idleWinV5
InputState>>idleLoop
[] in InputState>>forkIdler
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry
[] in ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>on:do:
[] in InputState>>forkIdler
BlockClosure>>ifCurtailed:
[] in InputState>>forkIdler
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry
[] in ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
ExceptionHandler(ExceptionHandlerAbstract)>>try:
BlockClosure>>on:do:
[] in BlockClosure>>newProcess

Any ideas on how to avoid this would be really appreciated.

Thanks,
Stefan

Stefan,

Most of the ODBC problems I've had have been with executing statements in
rapid succession; various finalization improvements in the database
connection have made it less of a problem over time.  However, it seems like
you are executing one query and getting into trouble??  That sounds more
like a driver problem, unless the #close is getting you.

Does the database need to remain in Paradox?  If not, you might be able to
import into Access or simply read the Paradox files - their format is
documented and a Google search should turn it up.  Since you mention recent
MS products, have you tried it on a Win98 box?  That would normally make
fnialization problems more likely to appear, but if it's a driver bug, it
might help, especially if you can move the data to another DBMS.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

On Sun, 27 Apr 2003 13:27:37 -0400,
Bill Schwab <[hidden email]> wrote:
> Stefan,
>
> Most of the ODBC problems I've had have been with executing statements in
> rapid succession; various finalization improvements in the database
> connection have made it less of a problem over time.  However, it seems like
> you are executing one query and getting into trouble??  That sounds more
> like a driver problem, unless the #close is getting you.

Hi Bill,

I fear that it will be the driver ... no hope for fixes there.
I thought about timing, too, and even waited a minute between
opening the resultset and inspecting it. The results were the same.

>
> Does the database need to remain in Paradox?  If not, you might be able to

yes. It comes from some administration software bought by one of my
clients for lot$ of money, which is a monstrous Delphi app, hence runs
straight on Paradox.

> import into Access or simply read the Paradox files - their format is

Funny thing, that. I can't import or link the Paradox tables into
Access, it gives a really stupid error message.

> documented and a Google search should turn it up.  Since you mention recent
> MS products, have you tried it on a Win98 box?  That would normally make
> fnialization problems more likely to appear, but if it's a driver bug, it
> might help, especially if you can move the data to another DBMS.

If no brilliant idea comes to me tonight, I will just write a minimal
Delphi app to export all of the tables into plain text files, tab
separated will do nicely, and then parse them back in again from
Dolphin.

Thanks for your time,
s.

"Stefan Schmiedl" <[hidden email]> wrote in message
news:b8gnpr$9ev6a$[hidden email]...
> I tried to connect to a (quite large) Paradox table from Dolphin 5.03
> via the ODBC driver supplied with either Windows XP or Office 2k, I
> don't know where exactly it originates.
...
> However, when I tried the same with a large table (233 fields, 2938
> bytes/record, 3410 records, 10922kB), the display in the left pane of
> the result set's inspector does not show the first entries, only the
> result set itself. After evaluating the query: message, the cursor blink
> rate in the workspace is about half the usual. Shortly
> after closing the inspector, (presumably) every garbage collection
> throws an exception until finally Dolphin crashes:
...

Try using an ADODB_Connection.  I don't know if anything will be different,
but it is probably worth a try.

Chris

On Mon, 28 Apr 2003 15:58:41 -0400,
Christopher J. Demers <[hidden email]> wrote:
Thanks for the idea, Chris, it works. Hoooooray.

I don't know why, but it works, at least for the first
experiments. Just from the looks it seems as if the ODBC methods
tried to pull in the whole table, and maybe got shot in the back
by a (for them) unexpected garbage collection, while the ADO methods
need to present only one record (the current in the recordset)
towards Dolphin. Of course, this is just a wild guess.

But since the ADO stuff uses the ODBC stuff, I guess that the ODBC
drivers are working correctly.

Now, is it just me, or is ADO really that much slower than ODBC?
Luckily it does not matter for this application.

Thanks again for the help.

s.

On 29 Apr 2003 18:24:51 GMT,
Stefan Schmiedl <[hidden email]> wrote:
> I don't know why, but it works, at least for the first
> experiments. Just from the looks it seems as if the ODBC methods
> tried to pull in the whole table, and maybe got shot in the back
> by a (for them) unexpected garbage collection, while the ADO methods
> need to present only one record (the current in the recordset)
> towards Dolphin. Of course, this is just a wild guess.
>

Of course I was wrong. :-)

I found a method getRows, which reads the whole lot into a
two-dimensional array (according to the docs), and this works
with ADO, too. Speedwise it's also acceptable, so my previous
experience was probably due to swapping or whatever.

s.

On 29 Apr 2003 19:13:06 GMT,
Stefan Schmiedl <[hidden email]> wrote:
And to conclude the story: I even managed to build a DSN-less
ADO-connection to the legacy tables. Don't ask how long it took
to recognize the last blank in the driver name below. -------+
                                                             |
[ :sql | | connection recordset result|                      |
  connection := ADODB_Connection new                         V
    connectionString: 'Driver=Microsoft Paradox-Treiber (*.db );' ,
      'DefaultDir=C:\WINBASYS;DriverId=538;FIL=Paradox 5.X;' ,
      'MaxBufferSize=4096;PageTimeout=10;';
    open;
    yourself.
  [
    recordset := ADODB_Recordset new.
    recordset open: sql activeConnection: connection
        cursorType: 1 lockType: -1 options: -1;
      getRows.
  ] ensure: [ recordset close. connection close]
] value: 'select * from kurse'

So I am happily back in Smalltalk-land and can finally start
building the filter to end all filters :-)

s.

"Stefan Schmiedl" <[hidden email]> wrote in message
news:b8mg1i$bjdg1$[hidden email]... blink
> >> rate in the workspace is about half the usual. Shortly
> >> after closing the inspector, (presumably) every garbage collection
> >> throws an exception until finally Dolphin crashes:
> > ...
> >
> > Try using an ADODB_Connection.  I don't know if anything will be
different,
> > but it is probably worth a try.
>
> Thanks for the idea, Chris, it works. Hoooooray.
>
> I don't know why, but it works, at least for the first
> experiments. Just from the looks it seems as if the ODBC methods
...

I seem to recall that there were some fixes to ODBC finalization in recent
patches.  I wonder if that may have had some negative impact on your ODBC
experience.  You might try our ODBC code in an older image.

Chris