<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Thomas,<div><br></div><div>many thanks for your reply! </div><div><br></div><div><div><blockquote type="cite"><div><br><br>the declaration of the wrapper function looks correct. For the ind_ptr<br>argument you could actually pass an array of booleans instead of some<br>structure,</div></blockquote><div><br></div><div>I might try this instead, and see if I get the same error ... But I find your arguments against using OCI_GetStruct very convincing, and though my present goal is a mixture of just being able to write racket code against an Oracle database and implementing bindings  to (some part of) the OCILIB library, it's perhaps not worth the effort in this case. (The whole point of using OCILIB being that you don't have to plunge into the depths of direct OCI programming - whenever I look up things in the OCI programmers guide from Oracle, I'm amazed how many things are handled for you by this free library :-) )</div><div><br></div><blockquote type="cite"><div><blockquote type="cite"><font class="Apple-style-span" color="#000000"><br></font></blockquote><br>For debugging the native code you can run Racket inside gdb, set signal<br>handling to ignore the segmentation faults triggered by Racket's memory<br>management mechanisms and set breakpoints in the native functions you<br>are interested in.<br></div></blockquote><div><br></div><div><br></div><div><br></div>That's good to know, in case I absolutely have to - but here, I will do as you suggest and just use the single-column access functions (which doesn't keep me from fetching into racket structs anyway :-;)</div><div><br></div><div><br></div><div>Ciao, and thanks for the help,</div><div><br></div><div>Sigrid</div></div></body></html>