HELP: image crashes when calling ODBC functions 
Author Message
 HELP: image crashes when calling ODBC functions

Hello all,

I would like to ask those of you who have had an experience with calling
Windows 95 ODBC functions from Visual Works 2.

I have a problem with converting the built-in Smalltalk 'char' type
to the 'UCHAR' required by ODBC functions. They are outwardly compatible
and when I pass a 'char *' string to a function that wants a 'UCHAR *' string,
there is no error. It even works for ordinary fields.

But if a database field has the NULL value, and I try to read this value
into a 'char *' string generated by Smalltalk, I get the system message
'Runtime error' - 'R6018 - unexpected heap error'. Then my image quits.
It is funny that this does not happen immediately after the Fetch call,
but after all processing is done. (Perhaps during garbage collection?)

I *do* specify SQL_NULL_DATA as the last parameter to SQLBindCol, but
it does not help.

I have found a workaround of calling my own DLL function, allocating
a 'UCHAR*' string there and passing it back to Smalltalk which thinks
this is a 'char*' string. But this is ugly.

So, question No. 1 is: how do I create 'UCHAR*' strings from inside Smallalk?
By the way, if I use C and pass a 'char*' string in the same situations,
nothing bad happens.

While I am at it, here is question No. 2. When I free an ODBC statement,
the function returns SQL_INVALID_HANDLE. But when I call after that
SQLError to find out what has gone wrong, it returns SQL_NO_DATA_FOUND,
that is, 'There was no error, stupid'. Do you know what's wrong?

Thanks a lot in advance,
Simon

 _________                Simon (Vsevolod ILyushchenko)
|       x |

|_________|   (For all normal mail)

Disclaimer: This is not me. This is just my mailer talking to your mailer...



Fri, 06 Aug 1999 03:00:00 GMT  
 HELP: image crashes when calling ODBC functions

Quote:

> I would like to ask those of you who have had an experience with calling
> Windows 95 ODBC functions from Visual Works 2.

I have developed a ODBC, SQLServer and currently I'm working in a Oracle
OCI driver, and in a Gupta SQLBase. We have a commercial product called:
BFT DatabaseBuilder (currently in beta) that has those drivers. As matter
of fact, BFT DatabaseBuilder is more than just an "interface" to those
drivers. It hides the diferences between them. It provides automatic
mapping of classes to tables (, supporting complex objects like
OrderedCollections, Sets, Bags, Dictionaries, etc. It has a diagram tool
that allows you to build your object model graphically. You can download
the beta from: http://www.bftsystems.com.

Quote:
> I have a problem with converting the built-in Smalltalk 'char' type
> to the 'UCHAR' required by ODBC functions. They are outwardly compatible
> and when I pass a 'char *' string to a function that wants a 'UCHAR *'
string,
> there is no error. It even works for ordinary fields.

> But if a database field has the NULL value, and I try to read this value
> into a 'char *' string generated by Smalltalk, I get the system message
> 'Runtime error' - 'R6018 - unexpected heap error'. Then my image quits.
> It is funny that this does not happen immediately after the Fetch call,
> but after all processing is done. (Perhaps during garbage collection?)

> I *do* specify SQL_NULL_DATA as the last parameter to SQLBindCol, but
> it does not help.

> I have found a workaround of calling my own DLL function, allocating
> a 'UCHAR*' string there and passing it back to Smalltalk which thinks
> this is a 'char*' string. But this is ugly.

> So, question No. 1 is: how do I create 'UCHAR*' strings from inside
Smallalk?
> By the way, if I use C and pass a 'char*' string in the same situations,
> nothing bad happens.

It seems that you have problems with SQLBindCol. If I'm right, you're
trying to bind the buffer used by ODBC to pass you back the results. The
SQLBindCol declaration is:

RETCODE SQLBindCol(HSTMT hstmt, UWORD icol, SWORD fCType, PRT rgbValue,
SDWORD cbValueMax, SDWORD FAR *pcbValue)

I recommed you declare this function in this way:

SQLBindCol: hstmt icol: icol
        fCType: fCType rgbValue: rgbValue cbValueMax: cbValueMax pcbValue:
pcbValue
        < C: short _Pascal SQLBindCol(unsigned long, unsigned short, short,
unsigned long, long, unsigned long) >
        ^self error: 'Function error parameter #', _errorCode parameter asString.

Instead of using UCHAR * (PRT), I'm using "unsigned long". This gives me
the freedom to pass whatever I want. Then you can allocate the buffer using
the following code:

        buffer := CIntegerType unsignedChar malloc: bufferSizeInBytes.
      bufferAddress := buffer asInteger.

Then pass this bufferAddress as the parameter of rgbValue in SQLBindCol.

It's very important that you use malloc instead of trying to pass directly
an instance of String, because if you pass a simple smalltalk string
VisualWork will copy this string to the heap when you call the function.
Then, when the function has finished, VisualWork will loose the reference
to the copied string (the CPointer), and it will be garbage collected
freeing the memory. It's important that you realize that you're not passing
the string, VisualWorks will copy it to the heap for you, and then VW will
pass this pointer to the function. There are no problems to pass simple
strings in most of the functions (like in SQLExecDirect), but in
SQLBindCol, ODBC will store this pointer for later use.

Quote:
> While I am at it, here is question No. 2. When I free an ODBC statement,
> the function returns SQL_INVALID_HANDLE. But when I call after that
> SQLError to find out what has gone wrong, it returns SQL_NO_DATA_FOUND,
> that is, 'There was no error, stupid'. Do you know what's wrong?

If you're receiving a SQL_INVALID_HANDLE, your handle is not longer valid
(I'm very smart :) ), then you should not call SQLError, because the error
is self explained.

I can look at your code and give you some advices if you want. Please send
me an e-mail.

Luis Roux
BFT Systems, S.A. de C.V.
Ave. Primero de Mayo 320 Oriente. Zona Centro.
CD. Madero, Tamaulipas. Mexico. 89400.
phone:  011-52-12-10-2908.
fax:  011-52-12-10-2908.

web: www.bftsystems.com



Sun, 08 Aug 1999 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. VC++ calling fortran function and fortran function calling a c++ function

2. : LabView crash using Call Library Function vi

3. LabVIEW crashing, call library function

4. call DLL's function too many times causes crashing

5. call DLL's function too many times causes crashing

6. simple win32file function calls cause python to crash

7. Help - Too Many Concurrent Unix Processes Crash Image

8. Tkinter with PIL crashing on large images - help

9. odbc: how to call a stored function in Oracle

10. How to find out name of calling function from called function

11. Help: ORexx crashing on MSSOAP client method call

 

 
Powered by phpBB® Forum Software