Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 10 of 16 total |
Defaults values do not work |
Sat, Mar 3 2007 10:24 AM | Permanent Link |
Altaireon | 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 |
Mon, Mar 5 2007 8:58 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Mon, Mar 5 2007 9:18 AM | Permanent Link |
"Jose Eduardo Helminsky" | 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 |
Mon, Mar 5 2007 9:30 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Mon, Mar 5 2007 10:06 AM | Permanent Link |
Altaireon | 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 |
Mon, Mar 5 2007 12:17 PM | Permanent Link |
"Jose Eduardo Helminsky" | 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 |
Mon, Mar 5 2007 1:09 PM | Permanent Link |
Altaireon | <<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 |
Mon, Mar 5 2007 1:28 PM | Permanent Link |
Chris Erdal | 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) |
Mon, Mar 5 2007 2:15 PM | Permanent Link |
Altaireon | 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 |
Mon, Mar 5 2007 3:51 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Wednesday, June 12, 2024 at 01:54 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |