Subject | Re: [ib-support] gbak restore corruption |
---|---|
Author | Ann W. Harrison |
Post date | 2001-03-30T17:29:18Z |
At 11:12 AM 3/30/2001 +1000, Geoff Worboys wrote:
to make it portable. Integer and floating point types introduce
alignment and 'endian' issues.
believe that the method I suggested will leave versions set at two or
possibly three for tables with triggers.
Regards,
Ann
www.ibphoenix.com
We have answers.
>And if I ever need to move to a different platform there is aI would suggest that you store all your data as text if you want
>good chance that gbak will not have problems with the backup database
>(since it does not have all the confusing constraints installed) and
>so I can move the backup database using gbak and then restore on the
>new platform.
to make it portable. Integer and floating point types introduce
alignment and 'endian' issues.
>One of the reasons for using gbak is to reset version numbers on theThe version number goes up on the commit, not on the statement. I
>metadata. Will the application of alter table commands to add
>computed fields, constraints etc impact this? That is; do I get a
>version number increment for each and every computed field and
>constaint added - perhaps I can minimise this by attempting to add all
>such changes in a single alter table command.
believe that the method I suggested will leave versions set at two or
possibly three for tables with triggers.
Regards,
Ann
www.ibphoenix.com
We have answers.