Keep in mind this is just a suggestion and not necessary. It's just the way
I usually do things. There is no problem having that many input parameters
to a stored procedure.

Reason I have this habit is because I usually pump a database from whatever
source I am migrating from verbatim tables, etc. Then, using IBO I have a
datapump operation that works from the source tables directly into a stored
procedure designed to exactly match the source table. Then, inside the
stored procedure I process those records however appropriate for the new
database. I often have a new design so there are inserts into one table and
possible inserts or updates into other tables too. Or, perhaps a generator
value or whatever.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

-- We may not have it all together --
-- But together we have it all --

----- Original Message -----
From: "Scronkey" <ryan@...>
To: <IBObjects@yahoogroups.com>
Sent: Thursday, September 05, 2002 4:40 PM
Subject: [IBO] Re: further understanding of transactions in IBO


> OK, will try this, but I'm still unsure of how the sp should be set
> up.
> The table I'm importing into has 21 fields, and I'm not sure whether
> this is a good thing, to have an sp with 21 input parameters.
>
> If this is what I should be doing, then do I use the DSQL, accepting
> parameters (fields from BDE table), then pass those params onto the
> sp (using EXECUTE PROCEDURE)?
>
> Sorry if this is a little vague, it's just that I'm not overly
> familiar with sp's and not sure of their limitations.
>
> -Ryan
>
> --- In IBObjects@y..., "Jason Wharton" <jwharton@i...> wrote:
> > I recommend using a TIB_DSQL component with an EXECUTE PROCEDURE
> statement.
> >
> > Having the import operate via a stored procedure allows you to
> write a
> > simple program and then from there if changes are needed you have
> a point
> > where you can on the server customize what is taking place.