Subject | Re: [IBO] IB_SQL Script limit 64K |
---|---|
Author | Helen Borrie |
Post date | 2003-01-22T09:49:18Z |
At 09:00 AM 22/01/2003 +0000, you wrote:
maintain. Also, I know there is an upper limit on the size of script which
ISQL will handle - I think it is probably lower than 64K. 40K seems to
ring a bell...but a 40K script is too big for practical purposes as well.
It is good practice to run a series of scripts, e.g.
Script0: create the database, declare exceptions, domains, udfs and create
generators.
Script1: declare tables and primary keys.
Script2: triggers
Script3: foreign keys, indexes
Script4: stored procedures. I often do two scripts for SPs - one for the
lower-level procs, the next for the top-level ones.
Script5: DML script for populating control tables.
Script7: Drops, alters and recreates.
If you want to end up with this running as if it were one script, include
an INPUT statement at the end of each script (except the last, of course).
This sequence will take good care of most dependency situations but you can
vary your content and your includes to suit your specific database.
Helen
>Hi, I can't enter long scripts in IB_SQL script form.Must?
>I've noticed that tha form (in IBF_Script) uses a TRichEdit, that has
>a limit in the maximum lines allowed, while TMemo seems not (I've
>tested both in a form, side by side, pasting a very long script. In
>TRichEdit was truncated, in TMemo was not).
>Is there any reason to use TRichEdit instead of TMemo?
>If not it must be changed.
> If I want to run a script to build the database, it's too big for64K is too long for one script. It will make it very hard to
> TRichEdit.
> Using IBO 4.2Ib, Win2K, D6.
maintain. Also, I know there is an upper limit on the size of script which
ISQL will handle - I think it is probably lower than 64K. 40K seems to
ring a bell...but a 40K script is too big for practical purposes as well.
It is good practice to run a series of scripts, e.g.
Script0: create the database, declare exceptions, domains, udfs and create
generators.
Script1: declare tables and primary keys.
Script2: triggers
Script3: foreign keys, indexes
Script4: stored procedures. I often do two scripts for SPs - one for the
lower-level procs, the next for the top-level ones.
Script5: DML script for populating control tables.
Script7: Drops, alters and recreates.
If you want to end up with this running as if it were one script, include
an INPUT statement at the end of each script (except the last, of course).
This sequence will take good care of most dependency situations but you can
vary your content and your includes to suit your specific database.
Helen