I am using Oracle with Entity Framework. The database ids are generated using triggers and sequences.
I want to set up Table-per-Type inheritance, as described here. I've set the "CourseId" to be StoreGeneratedPattern of "Identity".
Everything seems to be fine, except when I insert a row. The table representing the base class (in the walkthrough linked above, the Course table) gets a generated ID as expected.
However the table representing the inherited class (in the walkthrough linked above, the OnlineCourse table) has a row inserted with the CourseId set to zero. This violates the foreign key constraint.
I assume it's something to do with the sequence of inserts. I imagine it should work like:
Insert the Course row
Retrieve the newly created CourseId value
Insert the OnlineCourse, using the new CourseId
However, this isn't working because it's just using the default value of the CourseId (zero) to insert into OnlineCourse.
Any ideas how to fix this?
Since #Campinho hasn't written up his suggestion as an answer, I will do it.
This article has some background on a bug in StoreGeneratedPattern in VS2010.
One of very important features in ORM tools is an ability to get data auto-generated by a database during the entity persistence back to your application. The Entity framework supports this feature by setting StoreGeneratedPattern in the configuration of persisted property. The StoreGeneratedPattern setting is available in both SSDL (Store schema definition language) and CSDL (Conceptual schema definition language) parts of the EDMX file. CSDL configuration allows you defining the reloading behavior in the Model-first approach but SSDL part is responsible for generating correct SQL commands which will persist the entity and reload auto-generated properties. Unfortunately for a long time this was the source of all problems.
The feature was very hard to use because of the annoying bug in the Entity designer. When we set the property in the designer, the value was saved only in CSDL part but not in SSDL part of the EDMX file and the feature didn't work until we opened the EDMX file as XML and manually modified SSDL part. This solved the problem but only until we updated our model from the database. The update always deleted whole SSDL part including our manual change so we had to do it again. Any incremental development of our models become a big pain. The workaround was using mapped stored procedures for inserting and updating entities and mapping result sets (returning auto-generated data) from these stored procedures back to the entity. Finally this bug is solved in Visual Studio 2010 SP1 and we can use StoreGeneratedPattern without any problems because the value is correctly set in both CSDL and SSDL parts and it is not overwritten during updating from the database.
If you have this problem install KB2561001.
I installed the hotfix and changed the StoreGeneratedPattern to "None" then back to "Identity" for the relevant Ids. I could clearly see the SSDL section had been updated to indicate the new setting.
Then everything just worked! I'm not sure what's going to be in the patch from Oracle that they think will fix the problem.
I filed a service request with Oracle and it turns out this is a bug in their provider.
BUG 13724992 - EF: ENTITY NOT UPDATED AFTER SAVECHANGES USING STOREGENERATEDPATTERN
A fix for this bug will be released in an upcoming patchset. However, which patchset in will be included in and when that patchset will be released is currently unknown. I will let you know as soon as this fix will be released.
Related
So the column in question was a lookup column, which i deleted in the unmanaged solution, and mistakenly created a new column with the same name. Dynamics by default will use the same auto-generated schema name based on the display name. So when I go to import the unmanaged solution in my dev environment into the production environment as managed, obviously it throws an error because of the mismatched of data types per column schema name.
Error returned by Azure Pipeline
So I did the sensible next thing, and went to delete this column in my dev environment. But oh no! There are object dependencies which prevent me from deleting it, okay I look at which objects depend on this column, it is a form, i remove the column from the form, go to delete and oh no again! There is still a dependency on the form I just deleted the column from.
So what do I do? I can't change the column schema name, I can't change the data type back to the data type that's currently in the managed solution. Is this when I open up a microsoft support ticket? Hopefully someone here has some insight. Thanks!
The attribute can be associated with a custom control. Try removing this custom control using the classic form designer. It should be visible on one of the field property tabs.
If the attribute cannot be found anywhere on the form using the classic or modern form designer, try this:
Create a solution with this form only. Export the solution as unmanaged. Extract the customization.xml from the zip. Edit the xml and remove all references to your attribute. Paste the customization.xml into the zip and import and publish the solution.
The only way to delete a managed component is to upgrade the solution. In your case, you can delete the field and dependency in solution and apply the upgrade to target environment. Please noticed that all data in this field would get deleted when you apply the upgrade. You may check this link for more detail
I am doing a coredata database migration using lightweight migration in xcode4.5, I kept on getting "Can't find mapping model for migration" when I set "NSInferMappingModelAutomaticallyOption" to "NO". If I set "NSInferMappingModelAutomaticallyOption" to "YES", lightweight migration passes without problem.
Here is the steps I followed:
add a new model version .xcdatamodelId
make changes on the entities (including adding a new entity)
select the newer versioned datamodel as the current version, generate the new NSManagedObject subclasses, and make correspondant changes to the code.
create a mapping model and make the source points to the old datamodel version and the destination points to the new datamodel version
create custom migration policy and hook it up with one of the mappings inside the
mapping model
set up lightweight migration with "NSInferMappingModelAutomaticallyOption" equals to "NO".
test migration on simulator with the database coming from an older build.
I followed all and steps talked on apple documents and didn't make any changes on the entity schema after creating the mapping.. I tried to clean the DerivedData folder in xcode, and also I check the "VersionInfo.plist" which contains the correct versions of my datamodel. For the unchanged entities their hashkey are matching.
However I still get this error when I tried to do an migration.... Quite frustrated now.. Anyone can help to give me some guid on this problem?
In Models context file it was mentioned
If you want Entity Framework to drop and regenerate your database
automatically whenever you change your model schema, add the following
code to the Application_Start method in your Global.asax file. Note:
this will destroy and re-create your database with every model change.
System.Data.Entity.Database.SetInitializer(new System.Data.Entity.DropCreateDatabaseIfModelChanges<HMS.Models.HMSContext>());
so I added this code in the Global.asax file inside protected void Application_Start().
Adding this line drops whole database when I do any changes in model class. Is there any alternate way to avoid this and still I can do Model changes?
i.e After performing changes in model when I rebuild and run my application, it drops my database and regenerate all the empty model tables. So I loose all my entered data and I want to preserve table data.
If you're using EF Code First 4.1, then, no, it will only drop and recreate. EF version 5 apparently supports dynamically changing the underlying database. It's in beta at the moment, but is available for production use if you want to try it out. You can install it through NuGet.
I've created an OSX app that uses the entity model builder and its related stuff, for simplicity consider the entity with only two NSString.
The app is in production and works fine, now I need to add new attributes to the existing entity (only one entity exists), but with new attributes the old saved files are not open, silently the app does't open them and the console doesn't contain any error/warning message.
I need to load old saved files, consider all new attributes are optionals and have defaults (also in code not only in model design)
All existing attributes continue to be present I've only added the new attrs.
How can I design applications able to work when the entity model change?
From OS X 10.5 onwards, there is data migration functionality to help you, as long as you make changes to the data model in a new version.
There is a good basic explanation and example here: http://www.timisted.net/blog/archive/core-data-migration/
and the Apple documentation is here: http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreDataVersioning/Introduction/Introduction.html
When I add stored procedures to a linq datacontext, by default visual studio prefixes the stored procedure with the sql schema that it is in. Is there any way to stop this? In our environment, the stored procedures may be moved to other schemas over time, and we will default the schema based on the sql user used to connect. Do I have to do this manually or can I somehow turn off the schema prefixes?
There doesn't appear to be any means of removing the schema from LINQ-to-SQL mapped stored procedures using the designer. All procs are mapped including their schema name, which (to be fair) is probably a good thing for most applications. And as with most things LINQ-to-SQL, change your database at your own peril. Too many database changes required LINQ-to-SQL dbml updates & rebuilds.
Digging deeper, the schema name is stored in the backing dbml XML file, and is then included in the generated designer.cs file which contains the functions / methods which are called.
// dbml
<Function Name="dbo.MyProc" Method="MyProc">
// designer.cs
[global::System.Data.Linq.Mapping.FunctionAttribute(Name="dbo.MyProc")]
public int MyProc()
If you manually edit the dbml XML file to remove the schema & save within Visual Studio, the code will be regenerated like this:
// changed dbml - removed the dbo schema
<Function Name="MyProc" Method="MyProc">
// the resultant generated code in designer.cs
[global::System.Data.Linq.Mapping.FunctionAttribute()]
public int MyProc()
Which worked for my account, logging in with dbo as default schema. I'll leave the testing up to you.
This might be a workable solution - the visual designer still works like this, other items can be added etc without breaking the schema-less function, and the function itself doesn't cause the designer to complain. Best of luck!