Changed existing entity model and manually updated SQL Server database but still get context changed error - asp.net-mvc-3

I have an existing MVC3 application and database that is on a SQL Server 2008 R2 and I had to add a bool item to an existing model.
After I added it to the model, I rebuilt and published the project. Then I opened up SQL Server Management Studio and went to the table and added the entry to the column as a bit, I had to make it nullable since the table already contains data.
I thought this would be all that I would need to do to get everything working. However I got this error:
The model backing the 'psllc_DB' context has changed since the database was created. Either manually delete/update the database, or call Database.SetInitializer with an IDatabaseInitializer instance. For example, the DropCreateDatabaseIfModelChanges strategy will automatically delete and recreate the database, and optionally seed it with new data.
I'm not sure what else to do, I went back to the code and changed the bool to bool? so it will be nullable but this didn't help either. I can't drop the entire database since it's full of data, however as a last ditch possibility I could drop this table and re-create it cause it only has a few entries, but I don't know if that will work. I'm not sure what else to do so any advice would be very appreciated.
Update
Since I'm not getting any responses, let me rephrase my question.
How should I update my database (a SQL Express mdf file) to add a bool Column to a Table that has data already? I need the database to match my updated MVC 3 Entity Code First model otherwise I get the above error.
Thanks

Since this is code-first, you should do this code-first: change the class and use EF-migrations to change the database. The way you do it, the model and the database may match, but the meta information in the database is not updated.
By the way, if you supply a default value, you can add a non-nullable column.

Related

Visual Studio 2013 Dataset Designer refresh relations

I have an application with a dataset linked to an sql server database. I have updated some of the names or foreign keys and primary keys in the sql server. How do I make those changes translate to the data set. For example, I had a primary key called fk_temsempl_xxxxx. I changed it to fk_temsempl on the sql database. How do I get that change to show in the dataset designer in visual studio?
I have tried running custom tool by right clicking on the dataset and clicking run custom tool. That didnt work. I tried configuring the table adapter of one of the tables where a change occured, but the name of the relation didnt change.
You actually just right click the relation and choose Edit Relation... or double click on the line (when the mouse cursor changes from arrow to drag symbol) but I honestly wouldn't bother; you'll then have further refactoring to do in the code anywhere the relation is used, and it can be heavily used by visual designers.
You also get the problem that VS may not help you with the refactoring: in data binding scenarios most things that can be a source of data can also be a collection of multiple things that can be a valid DataSource. They then rely on a string DataMember to determine which of the collections of data in the data source should be used for the data.
For example, when a bindingsource is bound to list a DataTable, the bindingsource.DataSource property might be the DataSet object that contains the DataTable, and thebindingsource.DataMemberis a string of "YOUR_TABLE_NAME". the BindingSource might not be bound asmyBindignSource.DataSource = myDataSet.MyDataTable`. Refactoring inside strings involves a find and replace
DataRelations in a DataSet are created from foreign keys as they were discovered when the relevant table(s) were added to the dataset but it is important to note that, like DataTables and everything else, they are NOTHING to do with the database schema objects at all - they aren't permanently associated with them, the dataset entities are just set up looking something like the database objects when they (dataset entities) are first created. DataTables are created from only those columns selected, and whatever .NET datatypes closely resemble the types output by the query. For a table of:
Person
------
Name VARCHAR(50)
SSN INTEGER
Birthdate DATE
If you created the table with SELECT * FROM Person you'd get a datatable with Name (string), SSN (int), Birthdate (datetime) but if you made a new datatable in the dataset based on SELECT LEFT(Name, 1) as Initial, PADLEFT(SSN, 20) as PadSSN, DATEDIFF(day, Birthdate, NOW()) as AgeDays FROM Person then you'd get a datatable of Initial (string), PadSSN (string), AgeDays (int) - i.e. the datatable looks nothing like the db table. This concept of disconnection between dataset and db is pervasive, and really the only things that relate in any way to the database are the properties that specify which DB table/column a particular DataTable/DataColumn relates to for purposes of loading/saving data. Your Person.Name datacolumn can be renamed to Blahblah, but it will still have a .SourceColumn property that is set to "Name" - that's how the mapping between dataset and db works; dataset is predominantly completely independent of the db. Renaming a DB column would require a change to the SourceColumn property only
DataRelations don't even have this notion of linking to the parent relation in the database; there's no SourceRelation or SourceFK proeprty because there is no need to. They're set up with the same rules and a generated name all based on the rules of the FK, but then they function independently and only within the dataset. If you rename or even remove an FK from the db the dataset will carry on working in the same restricted way it always did; adding a datarow to a child table when no aprent row exists for it will throw an exception - none of it anything to do with the FK in the db, and the DataRelation can have different rules to the FK (e.g it can cascade deletes when the FK is NOACTION) or even different columns. You can have more or fewer DataRelations than the DB has FKs
Run Custom Tool is not a "contact the DB and see what changes have occurred there and replicate them into the dataset", it is a "turn the XSD that describes the dataset into a bunch of C# classes that implement strongly typed dataset/table/relation/column etc objects". Any time you change the XSD by making an edit in the visual designer and hit save, the custom tool is run. If you edit the XSD directly in a text editor you may need to run it manually to have your changes reflected in c# classes
Reconfiguring a tableadapter probably won't do anything to the relations either; its solely concerned with changing the datatable and tableadapter. If you really want to refresh the relations, delete the datatable from the set and recreate it. Be prepared for a potentially significant mop up/refactoring of code

SAP Business Objects 3.1 XI problems on regenerate structure

I have problems to refresh the structure of a table in my universe.
We have added some data to a reference table which is used in universe. After checking the new data in (Oracle 11g) database, found everything OK.
Then opened up designer in BO, imported the universe, looked up the associated table which only shows the existing items (not the new ones) - which seemed ok for me. I clicked on "View"/"Regenerate structure" but BO says that the structure does not need to be regenerated?
I have no idea what goes wrong and how I can add the new items to the table in my universe. Or do I have to update the content of a table differently?
It's possible that Designer isn't properly reading the database's data dictionary, and therefore not seeing the new column.
Data fields do not have to be present in the model in Designer in order for objects to reference them. So I would create a new universe object that references one of the new fields, and parse it. If it parses, then the field really is there and Designer just isn't seeing it. However if it doesn't work (i.e., you get an "invalid identifier"-type error), then the field is not there.
Joe's answer gave me the hint to check again why the new fields have not been there. And finally I found it. My "table" was a view which had to be actualized (SQL-select statement) and after that I could pick up the data into my universe and as shown in reports. Now everything is fine.

Saving copy of old table entry to another table when updating table entry with SaveChanges()?

Im working on an online store project where I have already made it possible for an administrator to update different table entries via the store gui (like items, user profiles, orders etc). SaveChanges(); is used to save the changes.
Im currently trying to figure out how to make this work:
An entry in table "items" gets updated.
Before the entry in the table "items" gets updated, a copy of the old entry gets saved into a table named "history-items".
The copy that is saved to "history-items" preferably has a timestamp.
How would I go about doing this? (As you might tell, I just recently picked up visual studio, and am pretty new to everything)
Thank you.
There are atleast 3 ways to do this:
If you are using SQL Server 2008 or newer this is now built in functionality, see: http://msdn.microsoft.com/en-us/library/bb933994.aspx
If you opt not to use that then the simplest solution is to use database triggers.
If you want to do it in C# code, then you need to read the original values before saving, and save these original values to the history table. For reading original values see: How to get original values of an entity in Entity Framework?
I would go for option 1 if possible.

Update EF model - DB at different location

I am very new to EF programming.
My application gets the data from existing database. (DB first)
Now I have come to situation where I want to update my model to newer DB. basically the core schema is same as previous but has some modification in the table.
When I change the DB name for app.config and update the model it gives list of error
have I missed something?
When you do an update it merges the model you have with the DB that you update from. Additional columns are added to your existing entities but columns that you have removed from the DB are not removed from your entities and you need to remove these mappings yourself.
If you know which tables have columns removed it sometimes easier to delete the entity from your model and then do an update to reload it from the DB.
If you've don't know what tables or there have been many then it may be easier to delete all entities from your model and just do a full Update to reload the the new DB structure.

Model changed during database created

I have uploaded my MVC3 project , it's s simple blog , at first it works well but after couple hours! following error appears (I've made custom error to Off to see the error)
The model backing the 'SiteContext' context has changed since the database was created. Either manually delete/update the database, or call Database.SetInitializer with an IDatabaseInitializer instance. For example, the DropCreateDatabaseIfModelChanges strategy will automatically delete and recreate the database, and optionally seed it with new data.
to solve this I have to manually delete my database and create again and then restore to the backup that I have created. but after after 2 hours again I get the error!
I really don't have any idea , what caused that ??
When you create a model and ask EF to create a database from it, EF would hash the model and store the hash value with the database. Whenever the context is created, EF recomputes the hash and matches it against what is stored at the database. If the model changes in any way, the resulting hash will be different and EF will throw the exception you have just seen. This is done in order to keep the model in sync with the database.
Is there any way the model could have changed during runtime?
One thing you could do to figure out the difference is to
1.Re-create the database from the model as you are doing now and get it scripted (script1.sql).
2.Wait till the error happens and delete the db and re-create it again and script it (script2.sql)
3.Try to compare the two and see whether you can spot a difference in the schemas.
This should give you an idea of what has changed in the model.
Goodluck

Resources