Re: Pro*C From Windows

vslabs_at_onwe.co.za (Billy Verreynne) wrote in message news:<1a75df45.0308252134.12d7b303_at_posting.google.com>...
> yitbsal_at_yahoo.com (Salaam Yitbarek) wrote
>
> > Oracle 8.1.7
> > OS Solaris 8
> >
> > I have a few stored procedures that use external procedures to access
> > shell scripts on the database server. These stored procedures are
> > called by VB (and other) applications on Windows platforms.
> >
> > I would like to rewrite many of these stored procedures using Pro*C
> > because a lot of the code is amenable to C and because I would like to
> > stop using external procedures. However, I don't know how to call a
> > Pro*C program residing on a Unix box from a Windows platform. I
> > suppose this is really a client-server question, but I don't know
> > where else to ask.
>
> Why? Why turn the extproc's into Pro*C? What business benefit are you
> trying to achieve?
>
> As for communicating from a Windows client to a C (or Pro*C) program
> on Unix, you need to roll your own client-server implementation -
> using good old sockets on Unix and Windows. And keep in mind things
> like server loading (fork()'s create processes and not threads),
> security, access via firewalls and proxies, SSL, etc. etc.
>
> But seeing that Oracle already provides a robust working and secure
> network layer THAT DOES ALL THIS, you should think twice about doing
> your own when you don't know a bind() from an accept(). Never mind the
> Visual Basic dweebs that have yet to discover Real Programming (tm).
>
> IMO, Pro*C is crap. Whatever can be done in Pro*C, can usually for the
> vast majority of times, be done better INSIDE Oracle (PL/SQL or Java).
> What's more, PL/SQL is many times more portable than Pro*C. You do not
> sit with issues about ld and dso and 32bit versus 64bit and all that.
> What's more - the PL/SQL code can be updated and recompiled from a
> client.
>
> It's strange you know.. here I am shouting at the developers and
> management for choosing Pro*C and not PL/SQL with extprocs (as the
> exception when PL/SQL and Java are not capable).. and there you have a
> decent Oracle config and now you want to bugger it up and turn it into
> a Pro*C abortion.. <sigh>
>
> So many friggen nutters and only one lead pipe...
>
> Oh yeah - if cmdline access to shell scripts is what you want, that
> can be very easily and nicely be done using Java in Oracle and
> wrapping that with a secure PL/SQL script. Or else implement RSH or
> REXEC on the client side and fire up th daemons on our Sun box. (go
> and look at asktom for the code)

Look, thanks for the tip to look in asktom.

The reason I wanted to move away from external procedures is that I have found them unstable, especially when dealing with file i/o. I do successfully use external procs in production, but they have been a headache to create. For example, just the other day, I was creating one to run call a shell script to run sqlloader, and it just wouldn't work. It returned the usual extproc error, and I traced the error to the call to sqlloader. The C code worked, but when called from a stored proc, it wouldn't. Received on Wed Aug 27 2003 - 08:21:39 CDT