Tim:

Default values are not being inserted into respective fields when a new record is inserted in an ElevateDB dataset.  Of course this all worked
fine with DBIsam 4.x (I am sure you've heard this allot lately, but I need to restate the obvious so at least you know it was working before
and still works when I switch back to DBIsam 4.x).  

I have not changed the default expression(s) since using the DBIsam migration tool.  I am using them as is so is there something else that
needs to be done in order for this to work?  I could always use the OnNewRecord event of the dataset to pre-populate default values, but
would rather do it in the database since It would only need to be defined once.

BTW:  Problem number 2232 is indeed fixed for me and works fine in the latest build.  I appreciate your efforts in addressing this issue.

Tom

Tom,

<< Default values are not being inserted into respective fields when a new
record is inserted in an ElevateDB dataset. >>

Default values in EDB are not populated until the row is actually inserted
because they need to be evaluated on the database server and may reference
other column values in the row that may not be available until insert time.

<< BTW:  Problem number 2232 is indeed fixed for me and works fine in the
latest build.  I appreciate your efforts in addressing this issue. >>

Thanks for the feedback.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

<< Default values in EDB are not populated until the row is actually
inserted
because they need to be evaluated on the database server and may reference
other column values in the row that may not be available until insert time.
>>

I understand the point but it can bring the default values at INSERT time
and can be re-evaluate at POST time.

For example: A field called F1 with CURRENT_DATE as default value and
*before* post the record I need to populate another field with F1 + 100
days, and show to the user to choose if accepts or changes the value before
post.

IMO, if the default value does not reference another column value then it
can be populated at INSERT time (like DBISAM does).

Eduardo

Eduardo,

<< I understand the point but it can bring the default values at INSERT time
and can be re-evaluate at POST time.

For example: A field called F1 with CURRENT_DATE as default value and
*before* post the record I need to populate another field with F1 + 100
days, and show to the user to choose if accepts or changes the value before
post.

IMO, if the default value does not reference another column value then it
can be populated at INSERT time (like DBISAM does). >>

Yes, but we can't selectively populate default values like that, and we
certainly can't be constantly changing the default values if they are
dependent upon other columns.  That's what computed columns are for.

Also, I'm not sure if introducing another round-trip to the database server
to get the defaults on every insert is a good idea.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim:

Then it would seem pointless to define a default value for a required field.  The dataset will complain about needing a value when you post the record long before being
inserted into the database (which is the problem I am having now) eventhough a default value is already defined for the field.   

Frankly, I believe DBIsam's default value handling mehanism is a strength and ElevateDB's inability to mimic this behavior is a weakness; however, I am sure there are
other considerations, and if as you say this could adversely affect performance then I will need to reconsider my strategy for handling default values.  

DBIsam was the first database I ever used that handled prepopulating default values properly.  These kinds of business rules are best defined in the database and not on
the client.  Having to define them in both places can be problematic - another maintenance issue/headache.

So its back to assinging values to required fields on the onNewRecord event.  If you tell me that this is the "Best Practice" and "Preferred Method" for handing default
values for required fields with ElevateDB then that's what we will do.  Give me your expert opinion on this matter and we will move forward with it one way of the other.

FYI:  This is a significant departure from DBIsam 4.x.  It would have been useful to know about this difference beforehand.

Keep up the good work.  Your efforts are appreciated.

Tom

Tim

My dictionary sad:
"Default value": Initial values to populate the field and user can change
this *before* post it.

If I understood the situation correctly then "Default value" only be applied
just before the record post. If I can put my opinion here then the behavior
could be the same as DBISAM and Computed Columns is another thing.

Eduardo

<<If I understood the situation correctly then "Default value" only be applied
just before the record post. If I can put my opinion here then the behavior
could be the same as DBISAM and Computed Columns is another thing.>>

Eduardo

In all faireness to ElevateDB this behavior is more inline with Oracle, MS SQL Server, etc.  However, upgrading a DBISam database to ElevateDB, I expected ElevateDB's
default value mechanism to work the same as DBISam 4.  I was suprised that it did not.

The work around is what I had mentioned before.  use the default expression/values property for the fielddef, or assign the default value(s) via the OnNewRecord event of
the dataset.  It is exactly what we do when working with any other RDBMS like Oracle, Interbase, MS SQL Server, etc.

Tom

Altaireon <tjm@altaireon.com> wrote in
news:9E9FCF84-0834-4D45-AFE8-B9D8D9DB7B1E@news.elevatesoft.com:

> The work around is what I had mentioned before.  use the default
> expression/values property for the fielddef, or assign the default
> value(s) via the OnNewRecord event of the dataset.  It is exactly what
> we do when working with any other RDBMS like Oracle, Interbase, MS SQL
> Server, etc.
>

Another "solution" might be to wrap the insert(s) in a transaction, read
the values inserted, and then commit or rollback depending on user choice.

Or won't the defaults be visible until committed?

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 3 + EDB 1.00 build 6)

Chris:

>>Another "solution" might be to wrap the insert(s) in a transaction, read
the values inserted, and then commit or rollback depending on user choice.

Or won't the defaults be visible until committed<<

There are certainly many ways to accomplish this, and your suggestion could possibly work.  Your suggestion, and previous comments in this thread only proves DBIsam's
mechanism for handling default values is by far the most elegant and requires the least amount of effort to implement.  It's one of many reasons why I've been partial to
DBIsam.

I vote for DBIsam's way of handling default values, but not at the expense of performace in ElevateDB.  The OnNewRecord event works just fine for me.  A little more
maintenance, a few more headaches, but it works just fine indeed.  

Tom

Tom,

<< Then it would seem pointless to define a default value for a required
field.  The dataset will complain about needing a value when you post the
record long before being inserted into the database (which is the problem I
am having now) even though a default value is already defined for the field.
>>

Yes, you'll have to turn off any TField.Required properties in such a case.

<< Frankly, I believe DBIsam's default value handling mehanism is a strength
and ElevateDB's inability to mimic this behavior is a weakness; however, I
am sure there are other considerations, and if as you say this could
adversely -affect performance then I will need to reconsider my strategy for
handling default values. >>

Well, one of the primary issues is date/time stamping.  DBISAM performed
defaults on the client, so it always used the client date/times, which is
not always desirable.   The second part of this (and probably most important
aspect), is the issues involved with the fact that we only get one chance to
populate the defaults.  Take the following situation, for example:

Defaulting occurs at Insert call time
Default value for a timestamp field is CURRENT_TIMESTAMP() and is intended
to timestamp the insert

If the user starts the insert, and then walks away for a few hours, then the
timestamp field is going to be way out of whack with what the actual insert
time is.

The developer can, however, get around these issues by using GENERATED
columns instead of DEFAULT expressions, so it may not be a huge issue.

I will look into this further and make a decision for build 2.    The
round-trip times on C/S may be insignificant enough that it doesn't matter.

<< FYI:  This is a significant departure from DBIsam 4.x.  It would have
been useful to know about this difference beforehand.  >>

Frankly, I simply missed it in the migration guide.  I knew that there would
be a few things like this that I missed since they are so subtle.  Either
way, I will update the migration guide accordingly after I make a decision
on what to do.

--
Tim Young
Elevate Software
www.elevatesoft.com