Current filter:
                                You should refresh the page.
                                  • See attached project.

                                    The database was created in VistaDB5 DataBuilder and each table has a Primary Key named ID which is an Identity index.

                                    The ORMDataModel Wizard was then used and the classes created. Each ID field is decorated with [Key]. Run the project and you will see the exception thrown.

                                    I have another project where changing the [Key] to [Key(true)] solves the issue but this one has me stumped.

                                Show all comments
                                • Michael (DevExpress Support) 07.24.2017

                                  Hello Glen.

                                  As I recall, we discussed this issue in the past: VistaDBConnectionProvider - Does not recognize identity (auto-increment) key columns. That time VistaDB didn't provide any documented means to retrieve information about identity columns from a database. We need additional time to re-evaluate this functionality with the current VistaDB version. We will update this ticket once we have any results.

                                • Glen Harvy 07.24.2017

                                  OK but if I change the [Key] to [Key(true)], the error does not go away.

                                • Glen Harvy 07.24.2017

                                  and the Indexes aren't imported either.

                                • Glen Harvy 07.25.2017

                                  I wonder if I can get an indication as to when this can be resolved. My clients can't wait indefinitely for a fix and I may need to seriously consider reverting to VistaDB4 or ditching VistaDB altogether.

                                • Kendall Miller 07.25.2017

                                  We're happy to help with this issue - if we could have someone from DevExpress reach out to us at support@gibraltarsoftware.com we'll see what we can work out.

                                • Michael (DevExpress Support) 07.25.2017

                                  @Glen:
                                  I'm afraid I cannot tell you when the issue will be resolved. We will inform you once we have any news.
                                  As a workaround, manually change [Key] to [Key(true)] for known identity key properties. I tried this solution with your project and it helps when the database is created from scratch. However, if the database was modified when identity key properties were declared using [Key], the database returns an error:
                                  Error 174 (Provider v. 5.0.5.1338): Column cannot contain null value:  ID
                                  It seems that this issue can only be avoided by fixing the database file manually.

                                  @Kendall:
                                  Thanks for your response. We will contact you regarding this issue.

                                • Glen Harvy 08.01.2017

                                  This is urgent. I have already had to release workarounds to my clients and revert in some cases to Vistadb4. 

                                • Michael (DevExpress Support) 08.02.2017

                                  @Glen:
                                  We are working on the fix. However, I cannot provide any ETA for it. You will be informed when the status of this issue is changed.
                                  If this issue is still urgent for you even with the suggested workaround, please explain why.

                                • Glen Harvy 08.02.2017

                                  Because I stuffed up. 2 friggin years after VistaDB5 was released I made the ridiculous assumption that Xpo worked OK with it. Stupid me. No prior extensive testing,  just went and released my application and updated several clients installations.
                                  Hey, if you're to busy then fine. It's ti me I looked to EF and SQL anyhow. Frankly, XPO hasn't had any development work for years and clearly VistaDB is far from being used in the real world anyway.
                                  Thanks Michael, I appreciate your consideration,  really I do, but.....if you can see your way to get this fixed asap I would appreciate it.
                                  PS. Clearly it should not receive your priority because of just one effective user of Devexpress who is or will ever  likely to be impacted for the next 2 years...
                                  PPS. Your suggested workaround doesn't work in my real word application.

                                • Michael (DevExpress Support) 08.02.2017

                                  Thank you for the explanation. We've just fixed the issue. You can now request a hotfix. Once it is published, please test it in your projects and let us know if this helps.

                                • Glen Harvy 08.02.2017

                                  Thanks Michael, much appreciated. I'll keep in touch.

                                • Glen Harvy 08.09.2017

                                  I updated to the hotfix release and updated the project to that version. I then ran the ORMDataModelWizard and the wizard appear to not change any of it's code. The c ode is/was:

                                          int fID;
                                          [Indexed(Name = @"PK_Table2_ID", Unique = true)]
                                          [Key(true)]
                                          public int ID
                                          {
                                              get { return fID; }
                                              set { SetPropertyValue<int>("ID", ref fID, value); }
                                          }

                                  The project again threw the same error as before.

                                  Unfortunately the fix doesn't seem to have worked.

                                • Glen Harvy 08.09.2017

                                  OK. I created a new project, same as the first. Then deleted the related ORMDataModel wizard code. Then used the wizard to create the code. The following was generated:

                                      public partial class Table2 : XPLiteObject
                                      {
                                          int fID;
                                          [Key(true)]
                                          public int ID
                                          {
                                              get { return fID; }
                                              set { SetPropertyValue<int>("ID", ref fID, value); }
                                          }
                                          string fSomeText;
                                          public string SomeText
                                          {
                                              get { return fSomeText; }
                                              set { SetPropertyValue<string>("SomeText", ref fSomeText, value); }
                                          }
                                          int fSomeInt;
                                          public int SomeInt
                                          {
                                              get { return fSomeInt; }
                                              set { SetPropertyValue<int>("SomeInt", ref fSomeInt, value); }
                                          }
                                      }

                                  Note that the index was not imported for either table.

                                  The new project worked and the transaction was committed OK. You discovered this pretty quickly but the issue is in upgrading, not creating a new model.

                                  Deleting, regenerating and then linking/referencing/adding to a complicated ORM Data Model is not an easy or realistic option for me given numerous linked fields, indexes etc etc.

                                • Michael (DevExpress Support) 08.10.2017

                                  >>>I then ran the ORMDataModelWizard and the wizard appear to not change any of it's code.

                                  Unless I'm mistaken, the issue was that the wizard changed Key(true) to Key() because the identity column couldn't be determined. Now it leaves the correct attribute.

                                  >>>Note that the index was not imported for either table.

                                  The index is not imported because it is the default index of the PK column. XPO assumes it always exists.

                                  >>>You discovered this pretty quickly but the issue is in upgrading, not creating a new model.

                                  The issue demonstrated by the sample project you provided is caused by the fact that the data model doesn't match the database schema. If you update the model from the database after applying the fix, identity columns will have the correct Key(true) attribute and XPO will generate appropriate Insert commands for them. If you are still experiencing errors, provide us with the updated sample project for research.

                                  Note that if you have a database created or updated when the model was incorrect, this database cannot be used with the new model and cannot be automatically modified to match the new model. Please restore it from the backup made before the data model was changed.

                                • Glen Harvy 08.10.2017

                                  The issue demonstrated by the sample project you provided is caused by the fact that the data model doesn't match the database schema. If you update the model from the database after applying the fix, identity columns will have the correct Key(true) attribute and XPO will generate appropriate Insert commands for them. If you are still experiencing errors, provide us with the updated sample project for research.

                                  I used the original test project I sent you as per the link above. I then upgraded the project references from 17.1.3 to the hotfix 17.1.5. I then ran then selected the ORM Model and ran the "update from database". The keys were not changed and the project still throws the same error. See attached.

                                  Note that if you have a database created or updated when the model was incorrect, this database cannot be used with the new model and cannot be automatically modified to match the new model. Please restore it from the backup made before the data model was changed.

                                  This contradicts your first statement and has me somewhat concerned. You are inferring that XPO modifies the actual database in some fashion. My real concern is that I have clients that have upgraded to 17.1.3 usage and I trust that when I eventually release a working version of 17.1.5 there will be no need for them to restore anything let alone their databases to a version that is now over 3 weeks old.

                                  Can I assume that providing I regenerate the ORM using the 'master' blank database I maintain and that database has not been 'infected' by 17.1.3 then all will be OK? That's REGENERATE and not GENERATE a new ORMModel.

                                • Michael (DevExpress Support) 08.11.2017

                                  Thanks for the updated project. I replicated the issue in it.

                                  I suppose "testxpo.vdb5" is the master database. In this database, the ID column of both tables has is_identity=true. However, the "xpotest.vdb5" database used by the application has a different schema: the ID column of both tables is not identity (is_identity=false). Since your code doesn't initialize the ID property (assuming it is generated by the database because of the identity type), the Insert command fails with the VistaDB.Diagnostic.VistaDBException (Column cannot contain null value:  ID) error.

                                  It seems that the "xpotest.vdb5" database was created when the data model had the ID properties declared as IsIdentity=False. This database cannot be used with the new model and XPO doesn't provide methods to change the type of an existing database column. So, if you have a database broken by the application that calls UpdateShcema with an incorrect model, the only way to go I see is to restore the database from the last backup.

                                  As for version 17.1.3, there was no "infection" in XPO. All previous versions cannot determine the is_identity state of the database column in VistaDB.

                                • Glen Harvy 08.11.2017

                                  Thanks for re-visiting this.

                                  The issue I was having trouble coming to grips with is: why after deleting all the XPO generated code files contained within the project/solution does the OrmDataModelWizard in v17.1.5 still fail to generate the correct code from the current database file? I couldn't understand the requirement to restore a database file that should not be 'touched' in any way by XPO.

                                  It is in reality largely academic as I'm the only poor sod who has come across this and anyone using v17.1.6 and above won't even know it was a problem. I've done as you suggested and it seems to have worked so I thank you for the 'fix'.

                                  I've re-read this a few times now and it seems that the vistadb database was created by XPO and is not the original database I created. It all makes sense now. Once again, thank you.

                                • Michael (DevExpress Support) 08.14.2017

                                  Thank you for your feedback, Glen. Please let me know if I can help you further.

                                1 Solution

                                Creation Date Importance Sort by