Hi Avi,

We do a lot of ODBC FFI work in Squeak with great success, but I must
confess that we have very limited concurrency requirements (e.g. 5
simulatenous users).  In your opinion, where does the ODBC FFI plugin
begin to *not* work well as we have not experienced any issues from
the blocking behavior of FFI?

Also, what do you think it would take to implement a native ODBC
interface.  Would native interfaces require implementing native
drivers for each vendor's database that one was targeting?  I think I
know the answer to this question, but just checking.

For the record, we use Microsoft SQL Server and the ODBC FFI interface
with essentially no foul side effects of the blocking problem of using
FFI -- so I am a bit baffeled by folks hestitancy in using the ODBC
FFI library.

Regards,

John


On Mon, 29 Nov 2004 22:08:49 +0100, Avi Bryant <avi.bryant at gmail.com> wrote:
> On Mon, 29 Nov 2004 15:40:33 -0500, Welch, Ronald P (US SSA)
> 
> 
> 
> 
> <ronald.p.welch at baesystems.com> wrote:
> >
> > Avi,
> >
> > I assume pulling the Oracle support over to Squeak from
> > the VW port would still leave us with the synchronous
> > connection problem right? That is unless the "proper
> > Oracle support" was also ported over from as well VW
> > correct (or written from scratch, of course)? I am assuming
> > VW does not have the synchronous connection problem.
> > Is that a valid assumption?
> 
> Correct on all counts.  I don't think porting the Oracle driver from
> VW is an option, though, for licensing reasons and because I imagine
> their FFI/plugin API is quite different.  So it would have to be from
> scratch.
> 
> The OCI protocol isn't published anywhere, is it?  It would be great
> to have a pure-Squeak client like the JDBC "thin" Oracle driver, but
> it would probably involve some heavy reverse engineering...
> 
> Avi
> 
> 


-- 
If at first the idea is not absurd, then there is no hope for it. --
Albert Einstein