Subject | Re: [Firebird-Architect] Extended field/domain DEFAULT usage |
---|---|
Author | Jim Starkey |
Post date | 2006-01-04T16:21:13Z |
Dmitry Yemanov wrote:
table of two fields, stored a record letting the default value do its
thing, committed the transaction, backed up the database, restored the
database, attached the new, and selected the record. Nary the slightest
hint of SF #1047576 or its evil henchmen.
Bugs should be fixed, not declared as architectural.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>"Jim Starkey" <jas@...> wrote:Huh? Works just fine. Created the domain as per request, put it in a
>
>
>>>AFAIK, the main problem is in GBAK that will need to manage more
>>>dependencies.
>>>
>>>
>
>Adriano is correct.
>
>
>
>>Gbak? Gbak is a backup and restore utilities -- it serializes metadata
>>and data in an order than can be readily restored.
>>
>>
>
>Exactly. And a simple default clause referencing UDF (even not considering
>selects and procedures) makes a database backup unrestorable. The same issue
>exists with computed fields. You may find an example in SF #1047576. So far
>the conclusion is that both backup order and restore transaction management
>require modifications.
>
>
>
table of two fields, stored a record letting the default value do its
thing, committed the transaction, backed up the database, restored the
database, attached the new, and selected the record. Nary the slightest
hint of SF #1047576 or its evil henchmen.
Bugs should be fixed, not declared as architectural.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376