I'm working with an SQL Server database with about 50 tables and plenty of relationships between those tables. I have already written a backup and restore function which will retrieve all data from the model, export it to XML which it could then import again into a clean database. But maintaining this import/export is a lot of work when there are some major structural changes to the entity model. I want a more dynamic solution.
Is there a more dynamic solution to export data from an entity model and to import it back again into a clean database?
Oh, before I forget... I don't have direct access to the database itself, not it's connection. All I get and all I can use is this entity framework object...
I would be passing this back to your server support team. Seems a bit strange for an app developer to have to worry about data backup/restore.
Have you tried the SQL Server Publishing Wizard? It creates a nifty formatted SQL file that can be easily moved between application, I've also also used (with some search&replace based on regular expression) to move data from SQL Server to Oracle...
RegardsMassimo
Related
I maintain a Windows based application backed by SQL Server DB so there is a set of SQL entities, like tables, views. With time I add new features and fix bugs so schema of the tables and views changes. Once I need to deploy a new version of the application I deploy the DB part by relying on DacPac/DacFx which automatically generates a difference between already deployed DB and the supplied DacPac so the already deployed DB is altered to match the DacPac's content. This way I don't have to write a code which compares 2 schemas and then generates a difference - DacFx does that for me.
That works well but now I need to expand the application so it also supports SQLite DB, I will for sure have to create a new application layer working with SQLite which is doable but one place I need help with is being able to create and maintain SQLite DB schema in the same way I do for SQL Server with DacPac/DacFx so a difference in schemas is computed and applied. While doing that I ideally want do write the SQL schema once so it could be applied to SQL Server as well as SQLite. Ideally, I need to generate SQLite schema based on the schema specific to SQL Server.
I looked into sqldiff which is capable of generating difference between 2 SQLIte DBs and thought I could:
use a technique from here to migrate SQL Server schema to SQLite
generate a temporary SQLite DB based on the generated above schema
compare the above deployed temporary DB to an existing SQLite DB by using the sqldiff and finally apply the difference to the target SQLite DB
but the sqldiff, as stated in the Limitations section:
The sqldiff utility is not designed to support schema migrations
In addition it has limitations around views:
The sqldiff.exe utility does not (currently) display differences in
TRIGGERs or VIEWs.
So I interpret that like that tool could probably be used for some migration cases but it is not really recommended.
How do you suggest generating and applying the schema differences?
I'm also interested to know how others solve the task of incrementally updating schema of their SQLite DB even if I take SQL Server completely out of equation and would instead maintain SQLite schema, in the source code, only. Does everyone create their own schema comparing tools instead of using something similar like DacFx in SQL Server world?
I would like to create a simple console app that automatically copies the database from one server to another... I want the logic to be loosely coupled with the models...
The logic should work as long as the app has access to both servers.
I don't want to create a backup, I want to access the live database on one server and copy it to another without first backing it up.
Can .NET EF Core do that for SQL Server database?
Using backup is by far the best way. It also guarantees transactional consistency. If transactional consistency is for some reason not important, you can use bcp: https://learn.microsoft.com/en-us/sql/relational-databases/import-export/import-and-export-bulk-data-by-using-the-bcp-utility-sql-server?view=sql-server-2017
What we do
We run a website that provides statistics. We used to run Access as a backend database, but now made the transition to SQL Server.
How we work
When we receive new statistics we put them in a staging table for proofreading and testing, before exporting them to the live database. Now we are using Access as a frontend for SQL Server with linked tables. This works fine.
What is the best way to having a Access database with staging tables that when ready can be exported to a table in SQL Server? Mind you that the final process should be fairly simple and not technical, as the reason for using Access is the relatively user-friendly UI. Using SQL Server Management Studio would be to technical for the users handling the data.
Let me stress that the solution we need is not a one-time conversion of a table or database, but for staging changes and then pushing them to SQL Server.
Ended up using linked tables and a local staging table which we upsized when the data is ready to be updated on production database.
https://support.office.com/en-us/article/Move-Access-data-to-a-SQL-Server-database-by-using-the-Upsizing-Wizard-5d74c0df-c8cd-4867-8d07-e6e759d72924
Here's some documentation on what I discussed in the comments. If you have never used integration services before the beauty of it is once the import procedure has been created it can be used over and over again.
So once you have the data in excel format, even access if you really wanted to you can follow the steps on the link below
Creating A Simple SSIS Package
I want to know how to convert an Access database file into a SQL Server (.mdf file) database?
The MS Access "Upsize Wizard" was discontinued with Access 2012. SQL Server Migration Assistant (SSMA) is now recommended. Reference: https://accessexperts.com/blog/2013/01/30/access-2013-is-here-but-wheres-the-sql-server-upsizing-wizard/
However, as Johnny Bones noted, I found it relatively easy to create a new empty SQL Server (2012) database and then import:
SQL Server Management Studio, R-click on the newly created Database | Tasks | Import Data -> SQL Server Import Wizard
I used "Access Database Engine" instead of "Jet Database Engine" for
no reason other than I GUESSED Jet was older. Mine is a throw-away
project you may want to research the difference.
I 'weeded out' the
Access queries (views) and just imported the tables.
So far it looks
like everything was imported OK.
The simple answer is; you can not "convert" an Access database to a SQL database. You can, however, import the Access database (tables only) into SQL. Remember that SQL is a true database, and, as such, contains no front end or GUI creation mechanisms. You will still need Access (or C# or VB or another front-end builder) to create the interface.
You may already know this, but in SQL Server a Query is called a View, and Modules are called Stored Procedures. You will need to convert your Access queries and modules accordingly if you're planning on having that all reside server-side.
It's actually pretty easy to import Access tables into SQL Server, you would just create a database on a server, right-click on the database name and choose Tasks --> Import Data. There you will choose Microsoft Access as your Data Source. The rest should be pretty self-explanatory.
JonnyBones wrote a good full answer. Other have made suggestions for tools which may work. However, the SSMA (SQL Server Migration Assistant) is likely to be the best option now. (See this youtube video for help with understanding some of the issues to overcome and an explaination of how to use SSMA.
Befre you consider using other tools, which may do more, you should find out why to use them instead of SSMA. Check out the youtube video as a starting point.
Be aware that the MS Access Upsizing wizard was great but is now discontinued, and there was a bit of a gap before MS created a decent version of SSMA, which is when&why these other tools came into existence.
SSMA should do what you need.
There are some access things that do not get moved to SQLServer and some that do.
eg Access triggers do not. Access tables constraints do, Access boolean datatypes so - of sorts - but you need to do some work. The video will explain most issues well.
Harvey
You can try with the Upsize Wizard or copy content of the table from SHOW TABLE DATA and paste to the target table with the same structure as the source.
We have an firebird database connected to our access control system and then a separate web app that I developed for our time and attendance using sql server 2005 as the data source.
I wanted to use entity framework to connect to the firebird database to access data like users, transactions, sites, etc. As this method is very complicated getting the connection using firebird .NET provider the other option I have is creating a sort of replication (Mirror) from the firebird database to sql server.
I have done this with a DTS previously (Selecting the data and then inserting it) and it worked fine but had many manual processes involved in getting the data and updates made it difficult.
Is there a simpler way to do this or any suggestions would be appreciated.
Unfortunately you need to track what to replicate at the data level. If you are only pushing it to the MS SQL database you could use a modified timestamp, or a record version field (create a generator, set a trigger to update the version field upon update) to reduce what you select. Another popular option is to update a field to current_transaction, but if you do a restore you will start counting from 0.
If you are sending data both ways it gets more complicated -- you need to have conflict resolution. You could look at something like the Microsoft Sync Framework which can use the methods above.