I want to access Microsoft SQL Server (7.0 or 2000), or eventually Teradata,
from a Solaris client.
SQL*Loader and such are usually server-side tools (aren't they?) and I
believe I want a client-side tool. For example, can I use a Microsoft
loading tool from Solaris?
I appreciate the help.
Dan
--
Dan Frankowski mailto:[EMAIL PROTECTED]
> -----Original Message-----
> From: Jeff Urlwin [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 16, 2001 3:20 PM
> To: Frankowski, Dan; 'Jeff Urlwin'
> Cc: [EMAIL PROTECTED]
> Subject: RE: bind_param_array for SQLBulkOperation ?
>
>
> What database are you using? Oracle or something else?
>
> I know, from my experience, that Oracle's SQL*Loader is VERY
> VERY fast, for
> example.
>
> I'll forward to you Dean's e-mails and a few others that are relevant.
>
> Regards,
>
> Jeff
>
> > -----Original Message-----
> > From: Frankowski, Dan [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, August 16, 2001 3:57 PM
> > To: 'Jeff Urlwin'
> > Cc: [EMAIL PROTECTED]
> > Subject: RE: bind_param_array for SQLBulkOperation ?
> >
> >
> > Sure, can you tell me where they are?
> >
> > I want to write the code one way or another because I'm loading
> > millions of
> > rows. I was planning to write a program in C to do it, and
> just call it
> > from Perl somehow. I think any of the following might help me
> > (in order of
> > desirability):
> >
> > - official DBI changes
> > - official DBD::ODBC changes
> > - Standalone Perl library that doesn't interfere with our
> > official ODBC::DBD
> > library
> > - C code to do it that (roughly) stands alone from DBD::ODBC
> > - unoffical DBD::ODBC changes
> >
> > The higher up you can get me on that list, the better for me. I
> > appreciate
> > the assistance.
> >
> > Dan
> > --
> > Dan Frankowski mailto:[EMAIL PROTECTED]
> >
> >
> > > -----Original Message-----
> > > From: Jeff Urlwin [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, August 16, 2001 3:01 PM
> > > To: Frankowski, Dan; [EMAIL PROTECTED]
> > > Subject: RE: bind_param_array for SQLBulkOperation ?
> > >
> > >
> > > Dan,
> > >
> > > Dean has recently (re)posted his patches and what I can tell
> > > you is that
> > > since the DBI spec doesn't have "bulk" interface, it has been
> > > determined
> > > that, for the short term, the array interface will be a
> > > DBD::ODBC private
> > > function.
> > >
> > > I could send you Dean's patches, if you want, but it's a
> > > moving target for
> > > DBI at the moment.
> > >
> > > Regards,
> > >
> > > Jeff
> > >
> > > > Folks,
> > > >
> > > > Summary: Can you tell me where to get a DBD::ODBC (or DBI) with
> > > > support for
> > > > bulk insert?
> > > >
> > > > Details:
> > > >
> > > > I am trying to insert millions of rows into various databases
> > > > using Perl DBI
> > > > and DBD::ODBC. It's taking a long time, and I was hoping
> > > to speed it up.
> > > > One idea is to use the ODBC 3.0 SQLBulkOperation API. I was
> > > > sadly going to
> > > > trundle off and try to write this.
> > > >
> > > > Then I found a very promising thread on the dbi-dev mailing
> > > list in late
> > > > January 2001 called "bind_param_array, bind_col_array".
> > > (See for example:
> > > >
> > > http://www.geocrawler.com/archives/3/184/2001/1/0/4978452/).
> > > Paraphrased,
> > > > Dean Arnold said, "I'm done with changes (except for
> > > cleanup), how do I
> > > > merge them into DBD::ODBC?" The next message in the
> > > Geocrawler archive
> > > > said, "The mailing list is moving to perl.org and the
> > > archives are at
> > > > symbolstone.org." Well, I can't seem to bring up any
> web page at
> > > > symbolstone.org. I can't even ping it (packets dropped).
> > > >
> > > > So I looked at the most current DBD::ODBC. CPAN tells me
> > > it is 0.28, and
> > > > the files look last modified in early 2000 (!). No
> > > bind_param_array.
> > > >
> > > > Even a look at Dean Arnold's code would be welcome, because I
> > > > could probably
> > > > just shamelessly steal most (if not all) of it.
> > > >
> > > > Dean Arnold's email address, maybe?
> > > >
> > > > Help appreciated.
> > > >
> > > > Dan
> > > > --
> > > > Dan Frankowski mailto:[EMAIL PROTECTED]
> > >
>
