ODBC causes Dolphin to crash or unable to save image

I tried doing this with a fresh image, too, but when I run this in a
workspace (a few times):

c := (DBConnection new) dsn: 'payment'; connect.
rs := c query: 'select ssn, firstname, lastname, paidthrudate, [last paid
date] as lastpaiddate from member'.
rs size.
c close.

Dolphin will either crash or won't let me save the image. If it won't let me
save the image, it gives me a debug. This is for a Paradox database, if that
makes a difference. It seems a lot more stable if I don't include the line
rs size.

Any pointers here?

Thanks!

Jen

Here's the call stack:

DevelopmentSessionManager(Object)>>error:
DevelopmentSessionManager(SessionManager)>>primSnapshot:backup:type:
DevelopmentSessionManager>>snapshot:
DevelopmentSessionManager>>snapshot
DevelopmentSessionManager>>saveImageDefault
[] in DevelopmentSessionManager(SessionManager)>>saveImage
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
DevelopmentSessionManager(SessionManager)>>saveImage
RefactoringSmalltalkSystem(SmalltalkSystem)>>saveImage
Symbol>>forwardTo:
CommandDescription>>performAgainst:
[] in Command>>value
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
Command>>value
ShellView>>performCommand:
SmalltalkWorkspaceDocument(Shell)>>performCommand:
CommandQuery>>perform
DelegatingCommandPolicy(CommandPolicy)>>route:
[] in Toolbar(View)>>onCommand:
BlockClosure>>ifCurtailed:
BlockClosure>>ensure:
Cursor>>showWhile:
Toolbar(View)>>onCommand:
Toolbar>>command:id:
ReferenceView(View)>>wmCommand:wParam:lParam:
ReferenceView(View)>>dispatchMessage:wParam:lParam:
[] in InputState>>wndProc:message:wParam:lParam:cookie:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>callback:evaluate:
InputState>>wndProc:message:wParam:lParam:cookie:
Toolbar(ControlView)>>defaultWindowProcessing:wParam:lParam:
Toolbar(View)>>defaultWindowProcessing:
Toolbar(View)>>onLeftButtonReleased:
Toolbar(View)>>wmLButtonUp:wParam:lParam:
Toolbar(View)>>dispatchMessage:wParam:lParam:
[] in InputState>>wndProc:message:wParam:lParam:cookie:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>callback:evaluate:
InputState>>wndProc:message:wParam:lParam:cookie:
ShellView(View)>>isDialogMessage:
ShellView>>preTranslateMouseInput:
ShellView(View)>>preTranslateMessage:
InputState>>preTranslateMessage:
InputState>>pumpMessage:
InputState>>loopWhile:
InputState>>mainLoop
[] in InputState>>forkMain
ExceptionHandler(ExceptionHandlerAbstract)>>markAndTry

"Jen Wu" <[hidden email]> wrote in message
news:[hidden email]... me
> save the image, it gives me a debug. This is for a Paradox database, if
that
> makes a difference. It seems a lot more stable if I don't include the line
> rs size.
>
> Any pointers here?

What you are seeing here is corruption of the Dolphin object memory, almost
certainly as the result of a buffer overrun. This could be because Dolphin
is supplying a buffer that is too small, but I think it more likely to be a
bug in the ODBC driver. I say that because the DBConnection stuff is mature
and has been stable for some time, and because ODBC drivers have often
exhibited this problem in the past (particularly the ones from Oracle, based
on anecdotal evidence only). A single byte overrun could very well cause
corruption of the Dolphin object memory because it is very tightly packed.

Regards

Blair

"Blair McGlashan" <[hidden email]> wrote in message
news:c54737$2of9lm$[hidden email]...
> What you are seeing here is corruption of the Dolphin object memory,
almost
> certainly as the result of a buffer overrun. This could be because Dolphin
> is supplying a buffer that is too small, but I think it more likely to be
a
> bug in the ODBC driver. I say that because the DBConnection stuff is
mature
> and has been stable for some time, and because ODBC drivers have often
> exhibited this problem in the past (particularly the ones from Oracle,
based
> on anecdotal evidence only). A single byte overrun could very well cause
> corruption of the Dolphin object memory because it is very tightly packed.

So, basically, the answer is: Don't use Dolphin with Paradox databases?
Yikes. I guess I won't be able to use Dolphin for this project, after all.
Off to figure out how to do this in Access ...

Jen

Jen,

> What you are seeing here is corruption of the Dolphin object memory,
almost
> certainly as the result of a buffer overrun. This could be because Dolphin
> is supplying a buffer that is too small, but I think it more likely to be
a
> bug in the ODBC driver. I say that because the DBConnection stuff is
mature
> and has been stable for some time,

Not that it's necessary, but I will second Blair's statement.  ODBC from
Dolphin "just works".  I don't recall ever having such severe problems with
it.  Early on, I had problems with exhausting available cursors, but such
problems would typically result in a walkback, not a crash.


> and because ODBC drivers have often
> exhibited this problem in the past (particularly the ones from Oracle,
based
> on anecdotal evidence only). A single byte overrun could very well cause
> corruption of the Dolphin object memory because it is very tightly packed.

Also merely anecdotal, I have heard bad things about the Paradox driver.

Have a good one,

Bill

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

"Jen Wu" <[hidden email]> wrote in message
news:[hidden email]...
> "Blair McGlashan" <[hidden email]> wrote in message
> news:c54737$2of9lm$[hidden email]...
> > What you are seeing here is corruption of the Dolphin object memory,
> almost
> > certainly as the result of a buffer overrun. This could be because
Dolphin
> > is supplying a buffer that is too small, but I think it more likely to
be
> a
> > bug in the ODBC driver. I say that because the DBConnection stuff is
...
> So, basically, the answer is: Don't use Dolphin with Paradox databases?
> Yikes. I guess I won't be able to use Dolphin for this project, after all.
> Off to figure out how to do this in Access ...

I have no idea how sound any of these ideas are: You might experiment with
using ADO from Dolphin.  It _might_ provide more insulation from the quirky
ODBC drivers, and MS may also have implemented additional workarounds for
quirky drivers in their code.  Another interesting, but potentially too
convoluted approach might be to create an MS Access database and link to the
Paradox tables.  Yet another, but not really pleasant option might be to
develop your own workaround by subclassing some of the Dolphin ODBC
implementation.  If you can narrow the problem down to a specific call you
may be able to pad some buffers a little more.

Chris

Jen,

> So, basically, the answer is: Don't use Dolphin with Paradox databases?
> Yikes. I guess I won't be able to use Dolphin for this project, after all.
> Off to figure out how to do this in Access ...

I doubt that's really what Blair meant.  However, most (if not all) of ODBC
runs in-process, and so Dolphin has no real protection from errant memory
access by a driver.  If the Paradox driver is stepping outside of the bounds
provided to it, then either Dolphin is offering too small a buffer (which
would probably end up being Dolphin's fault), or the driver is stomping on
memory it does not own.  If it's the latter, then any ODBC-based product is
running on borrowed time with that driver.  Smalltalk systems are
particularly sensitive to buffer overrwrites due to the garbage collector's
dependence on data in the object headers.

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:c54dhc$l4m$[hidden email]...
> Jen,
>
> > So, basically, the answer is: Don't use Dolphin with Paradox databases?
> > Yikes. I guess I won't be able to use Dolphin for this project, after
all.
> > Off to figure out how to do this in Access ...
>
> I doubt that's really what Blair meant.  However, most (if not all) of
ODBC
> runs in-process, and so Dolphin has no real protection from errant memory
> access by a driver.  If the Paradox driver is stepping outside of the
bounds
> provided to it, then either Dolphin is offering too small a buffer (which
> would probably end up being Dolphin's fault), or the driver is stomping on
> memory it does not own.  If it's the latter, then any ODBC-based product
is
> running on borrowed time with that driver.  Smalltalk systems are
> particularly sensitive to buffer overrwrites due to the garbage
collector's
> dependence on data in the object headers.

Exactly.

Thanks for the clarification Bill.

Regards

Blair

"Christopher J. Demers" <[hidden email]> wrote in
message news:c54cpi$2me00i$[hidden email]...
> I have no idea how sound any of these ideas are: You might experiment with
> using ADO from Dolphin.  It _might_ provide more insulation from the
quirky
> ODBC drivers, and MS may also have implemented additional workarounds for

Thanks! I'll give it a try ... is there a good place I can learn more about
ADO w/ Dolphin?

> quirky drivers in their code.  Another interesting, but potentially too
> convoluted approach might be to create an MS Access database and link to
the
> Paradox tables.  Yet another, but not really pleasant option might be to
> develop your own workaround by subclassing some of the Dolphin ODBC
> implementation.  If you can narrow the problem down to a specific call you
> may be able to pad some buffers a little more.

I don't think I'm going to go there ... if ADO doesn't work, I'll just come
up with a solution in Access -- it's a pretty small project.

Thanks again!

Jen