Subject Re: [ib-support] FB 1.0 and GBAK problems
Author Claudio Valderrama C.
"Daniel Rail" <daniel@...> wrote in message
news:5.1.0.14.2.20020325063925.00bdb270@......
> Hi Claudio,
>
> Just to let you know that I appreciate greatly the explanation and it
> clears my mind. The database in question returning the problem was a
> client's, but I also have a copy to work with. At least now, I know what
> to look for and how to find the potential problem record, if it occurs
> again and with another client. Even after changing the field size, it did
> give me an error the next time running my restructuring program, but my
> test case DB didn't give me any errors by following the same steps.

And I renamed a field with the debugger hooked and found absolutely nothing
abnormal in all the process. However, and this is only speculation mine, you
may regret renaming a field in multi-user environments, since the metadata
counter is not incremented, so no new version of the table is created.


> I don't think it was
> IB or FB's fault for what happened and I don't know what the circumstances
> would be when it actually did happen.

Maybe, but concurrency problems are tricky to understand and worse to trace.


> Anyway the best remedy that I've found here was to make the modifications
> in the field to eliminate the problem in the first place, now that I know
> how to find it. Also, to answer one of your questions as to why unicode
is
> used, we're using it in preparation for countries where it would be
needed,
> since our market is not limited to Canada and the US and we started to
have
> some interested people from China.

The only problem is that unicode only has a default, binary collation.
:-(

C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing