I have a separate copy of a sql server2008 database that we used to isolate data. I would now like to bring a few records into the production database from this separate database. I am not sure of the best way to do this, but I need to transfer several tables and ensure the relations remain. The easiest way I think of is to (if possible) create another dbml data context of the separate database and set all variables equal to a new object in the new database. I realized that I am getting many conflict errors. Is there a way to have two databases coexist like this in one application? There a few minor differences in the databases. The production database does have a few added rows.
Thank you for the help,
Chris
I'm no authority so perhaps someone can give you a better solution but it seems you can't have two models in the same project with an identical table name. What you could do is create a new project in your solution just to contain the model for the separate database.
This will let you have two models that both contain a "person" object for example because their namespaces will be different. Might help to put using statements at the top of your pages that use both models similar to the below:
using PersonLive = MyProject.Person;
using PersonIsolation = AlternateProject.Person;
Related
In .net core microservices, another team works on open source modules, and I extend their modules in my project. I already added one column in a Entity and then same column is added by open source team. Now duplicate column error is showing.
I can not alter open source migration files and my column is already in production.
How to resolve this issue please suggest.
i think we are dealing with multiple smells here.
each microservice should have its own Datarealm
by the sound of it you extended a Table of an object which was generated by the opensource service
But this does not help you, the question is can you merge the Data which is in this column.
If so you might get away with a simple copy/update.
What you need todo is:
Create a new Column With a different Name
Copy your existing Data into the new column
Drop your column
Execute your Migration
Copy your Data back into the column
Test your application very carefully, if the logic which you have implemented for the from you generated Data works as intended
Drop your backup column
Depending on the amount of Data this will lead to a downtime, so plan ahead and have a rollback strategy ready if something goes wrong.
Personal Opinion to Prevent those Smells
Every time i needed an opensource project in my projects in the past i wrote a wrapper around it, this has multiple benefits.
For one if the api of the project changes you only have to update it in exactly one place, which improves the maintainability.
Because it has a wrapper it automatically gets a own Database and if i need to extend an entity which i get from one of those opensource projects, i usually do it via Foreign Keys with a different Table. Which then gets linked via a view.
Yes this costs some performance, but in the end it was worth it every time.
I'm encountering a very odd problem. Since 2 days I cannot add new tables from my db in the model.
They appear in the list of addable tables, no error are shown at the validation but then, they don't appear in the Entity lists, and they still appear in the "addable" part of the menu.
The problem appears in
We've tried from different computeurs, so it's not a problem of my specific visual studio.
We've tried with other dbs, and the problem doesn't affect them. It affects boths of my prod and developpment dbs though.
We've tried with the exact same credentials to log to the db (not window authentication as we usually do), and the problem remains, so it's not a problem of rights.
We're a bit out of ideas right now :/
Does someone have an idea what it could be?
Thanks
Ok, we've found where it came from.
The table we wanted to add had no PK, and then when we tested we created mock tables without PK.
Once we add a PK the import goes well =)
If you're using a Code First approach then Entity Framework will build the table for you. It looks like you are not using Code First, so you will have create the table in the database. I assume you're using an Entity Data Model (.edmx)? If so, you will create your table in the database, then update your data model (.edmx). If you have not yet created your .edmx file, you need to do that - the .edmx file will contain all your CRUD operations.
What I'm confused about is I'd imagine your code would throw an error if the table did not exist (i.e. if the table represented by your data model didn't map to an actual table in the database, because it doesn't exist). So, the question is, does your table already exist? If it does, then step through the code line by line to find out why your records aren't being saved. If it doesn't exist, then add the table via SQL Server Management Studio (or similar), then open your .edmx file, right click on the layout that comes up, click "Update Model from database".
I'm having hard time to find the right solution to manage multiple modificable lookup tables (more than 40), most of them with the same structure. I'm using the repository approach but I can't make it work. Has someone a working example?
Take a look at my repository pattern for EF4.1/4.2 it allows you to easially connect to an EF4.1 DB and query it throughout your solution.
http://blog.staticvoid.co.nz/2011/10/staticvoid-repository-pattern-nuget.html
a working source application is also available here:
http://dl.dropbox.com/u/37129059/StaticVoid.Repository.Demo.zip
A tool that worked great for me is a t4 code generation template that generates enums out of lookup tables. It can save you a lot of work and keep your source code up to date when you add some new items to the look up tables.
I also use a DB with ~30 lookup tables and it was easy to set up, modify and use (even though I did not knew much about t4 templates before).
http://erraticdev.blogspot.com/2011/01/generate-enum-of-database-lookup-table.html
I'm using CoreData in my application for DML statements and everything is fine with it.
However I don't want use NSFetchedResultsController for simple queries like getting count of rows, etc.
I've decided to use fmdb, but don't know actual table names to write sql. Entity and table names don't match.
I've even looked inside .sqllite file with TextEdit but no hope :)
FMResultSet *rs = [db getSchema] doesn't return any rows
Maybe there's a better solution to my problem?
Thanks in advance
Core Data prefixes all its SQL names with Z_. Use the SQL command line tools to check out the your persistent store file to see what names it uses.
However, this is a very complicated and fragile solution. The Core Data schema is undocumented and changes without warning because Core Data does not support direct SQL access. You are likely to make error access the store file directly and your solution may break at random when the API is next updated.
The Core Data API provides the functionality you are seeking. IJust use a fetch request that fetches on a specific value using an NSExpressionDescription to perform a function. This allows you to get information like counts, minimums, maximums etc. You can create and use such fetches independent of a NSFetchedResultsController.
The Core Data API is very feature rich. If you find yourself looking outside the API for a data solution, chances are you've missed something in the API.
I'm creating a data model first using the LINQ-To-SQL graphical designer by using right-click->Add->Class. My idea is that I'll set up everything first using test repositories, design the entire website, then as a final step, create a database using the LINQ-To-SQL classes as a model for the database tables and relationships. My reasoning is that it's easy to edit the classes, but hard to modify DB tables (especially if there's already data in them), so by doing the database part last, it becomes much easier to design the structure.
My question is, is there an automatic way to link the two once I have the DB tables created? I know you can manually fill out the class properties for the LINQ-To-SQL entities but this is pretty cumbersome if you have a lot of tables to deal with. The other option is to delete your manually-created classes and drag the tables from the database into the designer to auto-generate the classes, but I'm not sure if this is the best way of doing it.
Linq to Sql is intended to be a relatively thin ORM layer over a database. While you can of course just add properties to a data context and use them as a sort of mock, you are correct, it isn't really easy to work with.
Instead of relying solely on Linq to Sql generated classes to give you freedom from the database implementation, you may want to look into the repository design pattern. It allows you to have a smooth separation between your database, domain model, and your middle tier; I have used it on two projects now, and have been able to (for the most part) build everything top-down, leaving the actual database for last. Below is a link to a good tutorial on the pattern (better than I could scribble down here).
https://web.archive.org/web/20110503184234/http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/10/08/the-repository-pattern.aspx
Depending on your database permissions, you may call your datacontext's DeleteDatabase() and CreateDatabase() methods as a ungraceful way of resyncing your classes and tables. This is not much of an option when you have actual data in the database, but does work when you are in your development stages.
Take a look at my add-in (which you can download from http://www.huagati.com/dbmltools/ , free 45-day trial licenses are also available from the same site).
It can generate SQL-DDL diff scripts with the SQL-DDL statements for updating your database with only the portions that has changed in the L2S model (e.g. add missing columns, missing tables, missing FKs etc), instead of the L2S-out-of-the-box support for recreating the entire db from scratch.
It also supports syncing the other way; updating the model from the database.