Re: "load from" and stored procedures

In article <8cul8h$pme$1@news.xmission.com>, "Obnoxio The Clown" <obnoxio@hotmail.com> wrote: > > From: Kate Juliff <kcj@mechoshade.com> > >That is, I have an ascii delimited file that I need to load into a > >table. I must do it via ODBC and so must used a stored procedure.... > > Erm. So you want to have your stored procedure get a file from your local PC > via ODBC do you? Anyway, LOAD FROM is a dbaccess function, it isn't anywhere > else. > > I think your best bet would be to ftp the file onto the server and fire up a > load on the server. If you must load from the client, you're going to have > to cut some code. I do not want to load from the client. I need the stored procedure to import data from an ascii delimited file that resides on the server, into a db that also resides on the server. But I need to initiate this FROM the client. On the server I have a program (ESQL C) that reads Cisam files and loads them into the database. The Cisam files and the db are on the server. All works fine. HOWEVER I cannot get the program to run unless I initiate it on the server. I've tried running it using a system call from a stored procedure. No go. So I removed the code that loads the table from the program and just had it write to an ascii delimited file, hoping to be able to load from it as the next step. Can't do that either. The part that writes the file works OK. My problem is not getting the data from the Cisam files into the db, but getting all this initiated from a client. Any suggestions welcome. And yes, I'm passing across and setting up the environment variables, Kate > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > > Sent via Deja.com http://www.deja.com/ Before you buy.

Kate Juliff wrote: > > In article <8cul8h$pme$1@news.xmission.com>, > "Obnoxio The Clown" <obnoxio@hotmail.com> wrote: > > > > From: Kate Juliff <kcj@mechoshade.com> > > > >That is, I have an ascii delimited file that I need to load into a > > >table. I must do it via ODBC and so must used a stored procedure.... > > > > Erm. So you want to have your stored procedure get a file from your > local PC > > via ODBC do you? Anyway, LOAD FROM is a dbaccess function, it isn't > anywhere > > else. > > > > I think your best bet would be to ftp the file onto the server and > fire up a > > load on the server. If you must load from the client, you're going to > have > > to cut some code. > > I do not want to load from the client. I need the stored procedure to > import data from an ascii delimited file that resides on the server, > into a db that also resides on the server. But I need to initiate this > FROM the client. > > On the server I have a program (ESQL C) that reads Cisam files and > loads them into the database. The Cisam files and the db are on the > server. All works fine. HOWEVER I cannot get the program to run unless > I initiate it on the server. I've tried running it using a system call > from a stored procedure. No go. > > So I removed the code that loads the table from the program and just > had it write to an ascii delimited file, hoping to be able to load from > it as the next step. Can't do that either. The part that writes the > file works OK. > > My problem is not getting the data from the Cisam files into the db, > but getting all this initiated from a client. Any suggestions welcome. > And yes, I'm passing across and setting up the environment variables, > > Kate > > > ______________________________________________________ > > Get Your Private, Free Email at http://www.hotmail.com > > > > > > Sent via Deja.com http://www.deja.com/ > Before you buy. If the file to be loaded has a constant name, could you write a sql script file and then execute it from within the SPL via the SYSTEM call? 1. contents of the sql file database xyz@sqlhost; load from "/path/path/file.txt" insert into table; 2. SPL code LET cmd = "dbaccess - /path/path/myscript.sql" SYSTEM cmd; Just a thought, I have no idea if it would bomb, and error handling would be a serious issue.