Subject | Re: [IB-Architect] Next ODS change (was: System table change) |
---|---|
Author | Dalton Calford |
Post date | 2000-11-15T19:46:06Z |
Hi Jason (I think I should start adding last names into my greeting -
too many Jasons kicking around here)
:)
The script consists of a series of interelated tables. (of course)
Where every table is given a unique ID, each Row in each table has a
unique ID, every trigger/procedure has a unique ID and they all have
cross related grants.
In order to create the system, involves huge amounts of stored
procedures, tables, generators etc (I think I sent you some of the
documentation on some of the date/time procedures a few months back)
The system really slowed down as more and more items were added.
The client was WISQL running a standard script (albeit the script was 92
MB in size). It was the dependancy trees that really got it down.
The funny part was, it worked without a hitch after the commit.
I was expecting all hell to break loose cause the origional database was
hand built, then the metadata was extracted, and then the script
massaged so that it would run.
Many times I have seen dependancy trees that were soo inter-related,
they would not extract/re-apply properly without alot of work.
Anyways, I would need to find the script/strip out the proprietary
stuff, convert it to work in a dialect 3 environment - alot of work.
My plate is currently full right now, but, I just found out that my
predecessor may be comming back to work for me. It will be good if he
does.
best regards
Dalton
Jason Wharton wrote:
too many Jasons kicking around here)
:)
The script consists of a series of interelated tables. (of course)
Where every table is given a unique ID, each Row in each table has a
unique ID, every trigger/procedure has a unique ID and they all have
cross related grants.
In order to create the system, involves huge amounts of stored
procedures, tables, generators etc (I think I sent you some of the
documentation on some of the date/time procedures a few months back)
The system really slowed down as more and more items were added.
The client was WISQL running a standard script (albeit the script was 92
MB in size). It was the dependancy trees that really got it down.
The funny part was, it worked without a hitch after the commit.
I was expecting all hell to break loose cause the origional database was
hand built, then the metadata was extracted, and then the script
massaged so that it would run.
Many times I have seen dependancy trees that were soo inter-related,
they would not extract/re-apply properly without alot of work.
Anyways, I would need to find the script/strip out the proprietary
stuff, convert it to work in a dialect 3 environment - alot of work.
My plate is currently full right now, but, I just found out that my
predecessor may be comming back to work for me. It will be good if he
does.
best regards
Dalton
Jason Wharton wrote:
>
> I would too. Especially since there are very likely some things that could
> be done to improve it. Did you try putting any indexes on the metadata
> tables?
>
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
> ----- Original Message -----
> From: <Schlottmann-Goedde@...>
> To: <IB-Architect@egroups.com>
> Sent: Wednesday, November 15, 2000 11:54 AM
> Subject: Re: [IB-Architect] Next ODS change (was: System table change)
>
> > Dalton Calford schrieb:
> >
> > > (I have a metadata build script that takes 89 hours to complete on a 450
> > > Mhz 500MB Ram IB 5.5 superserver/NT system - I was thinking of donating
> > > this as part of the test suite)
> >
> > I would really like to see that :-)
> > Something for the 90 Hour Vector Test.
> >
> > Frank
> >
> > --
> > "Fascinating creatures, phoenixes. They can carry immensely heavy loads,
> > their tears have healing powers and they make highly faithful pets."
> > - J.K. Rowling
> > http://sourceforge.net/projects/firebird
> >
> > To unsubscribe from this group, send an email to:
> > IB-Architect-unsubscribe@onelist.com
> >
> >
> >
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com