I have been tasked with migrating an existing MS Access database to SQL Server 2012. It appears that using the SSMA for Access is the best choice for completing this migration. I have done some review of the migration assistant and it seems to be pretty straight forward. The kicker is that this client wants to use the existing Access forms with the data that has been migrated to SQL Server. So once the migration is complete, I need to point all of the current Access forms, queries, and reports at the new data source. I am not sure of the best way to accomplish this. I see that there is an option to 'link tables' when using the migration assistant but I am guessing there is more work to do to get the entire access front end working with the SQL backend. I don't have much Access experience so any help or advice on the best way to accomplish this would be much appreciated. Thanks!
The SSMA tool can also redirect its table definitions (the entries under the 'Tables' tab in the database window) so that they reference the migrated data in SQL Server. Forms, queries and reports all use these table definitions, so you may well find that most things work as expected immediately after migration. However, there are some aspects that do not move successfully, and you are likely to hit some of these if there is much VBA code in your application.
Related
I have an Xamarin cross platform application. I am currently storing my data in a Sqlite Database. However we want to have bi-directional syncing with an Azure Sql Database. After much reading I decided to give Dotmim Sync a try. The initial sync worked, however when adding a column to a table and attempting to migrate the data (following the tutorial), I got an error stating that the tracking table was missing. I redid everything again and realized that the entity tracking table was never created and I am not sure why. However Sql created a tracking table but it was not the entity tracking table that the error stated was missing.
I am curious if anyone with Xamarin has been able to successfully create bi-directional syncing with Sqlite and Azure Sql using Dotmim Sync. I have yet to find anything else that will work. Other than hand jamming it in this tutorial: https://www.xamarinhelp.com/mobile-database-bi-directional-synchronization-rest-api/
I am not against that, just seems like a lot of room for error. I am hoping someone out there has had success with what I am trying to do.
Hello I'm using Dotmim sync to synchronize a Sql Server database with a Sqlite database hotsted in a xamarin forms application through an API.
I think that I had the same problem as yours.
The problem is, as far as I understood, that the tracking tables are created only on the first sync.
If you change the schema of those tables you will need to call the Deprovision method.
This method will re-create the stored procedures and the triggers with the new database schema.
I'll leave you the link to the docs:
https://dotmimsync.readthedocs.io/Provision.html#provision-deprovision.
I have an ERP system which I maintain with a team of people. However lately we seem to be loosing track of who's changing what and we need a solution to be able to control these changes. We are looking into the enterprise version of GIT as all our software development and web development would work perfectly with it. Not to mention I have some experience with GIT already.
The problem is we need the version control to extend to our SQL Server which we use SQL Server Management Studio to maintain. We have thousands of tables in 6 main databases which have a lot of stored procedures which are being changed.
It's not so much we want to control the source as in, permissions and refuse changes by people. It's more, we need a way of tracking changes and attaching explanations to help our future selves.
Does anyone know any solid solutions which would fit our purpose?
Assume the cost isn't a main factor.
I was using RedGate tool. It can integrate with Git.
RedGate SQL Source Control
I have been asking myself this question once. So I've found following solution which I can suggest you to use.
It is a SQL Server Data Tools that solves the problem.
The tools include SQL server database project for visual studio. This project will store your database structure. You can just add it to you solution. Then run a schema comparison with your database to take a snapshot of your current database state. You can choose what objects to compare. Since this moment your have all your changes being tracked by your VCS. Every change is documented now.
You can make changes in DB project and when you are done just run schema comparison, get the update script and apply those changes to your SQL server database. It is really not that hard to work with your schema from DB project as it provides intellisense, syntax validation. Also it is possible to write and execute SQL queries against you database.
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.
Is there seriously no way of using a shared access non-server driven database file format without having to use an SQL Server? The Entity Framework is great, and it's not until I've completely finished designing my database model, getting SQL Server Compact Edition 4.0 to work with Visual Studio that I find out that it basically cannot be run off a network drive and be used by multiple users. I appreciate I should have done some research!
The only other way as far as I can tell is to have to set up an SQL server, something which I doubt I would be able to do. I'm searching for possible ways to use it with Access databases (which can be shared on a network drive) but this seems either difficult or impossible.
Would I have to go back to typed DataSets or even manually coding the SQL code?
Another alternative is to try using SQL
Install SQL Server express. Access is not supported by EF at all and my experience with file based databases (Access, SQL Server CE) is mostly:
If you need some very small mostly readonly data to persist in database you can use them (good for code tables but in the same time such data can be simply stored in XML).
If you expect some concurrent traffic and often writing into DB + larger data sets their performance and usability drops quickly. They are mostly useful for local storage for single user.
I'm not sure how this relates for example to SQLite. To generate database from model for SQLite you need special T4 template (using correct SQL syntax).
Have you tried SQLite? It has a SQL provider, and as far as I know EF supports any provider. Since it's file-based, that might be a plausible solution. It's also free.
I m using Access 97 database.It has lots of forms. Data bulked. I have to upgrade it quickly. I bought SQL Server 2005 enterprise edition.
I want to use SQL Server for data holder. I m going to use Access forms regularly. I just want to export data to the sql server.
Is it possible to use "Linked" data storing?
While I agree with HLGEMs first paragraph I respectfully disagree with HLGEMs second paragraph. There are quirks you need to know about of which I'm somewhat ignorant. Such as changing boolean fields to LittleInt. But otherwise it's a lot of tedious work to recreate the database schema. And it'll be error prone such as missing indexes or relationships.
There is a tool from the SQL Server group which is a lot better than the Upsizing Wizard especially the Access 97 version.
SQL Server Migration Assistant for Access (SSMA Access)
http://www.microsoft.com/sql/solutions/migration/access/default.mspx
As you discover these quirks you can change the scripts to recreate the database with the appropriate changes.
I concur with Tony Toews (and you should trust him on this, he's an Access guru): use SSMA to help you move data to SQL Server, it does a more complete job than the upsizing Wizard integrated in Access (which doesn't work for upsizing to SQL Server 2008 anyway).
You have to be wary of a few caveat though; I've made a blog post about some of the things you should check out.
The point is that if the original Access database was designed without relying too much on the liberties that Access allows (strange characters in table and column names for instance), then the process will be much easier.
Pay special attention to all the warning and errors reported by SSMA, they are really useful in helping you focus on the issues you must solve.
With regards to performance, moving to SQL Server isn't necessarily going to make things faster.
In some areas it will actually be slower, sometimes much much slower:
Access is pretty good at optimizing certain forms of data access but once the database moves outside of its reach, it doesn't have as much control.
Most things will work fine though.
You will probably have to rewrite a few queries, maybe move them as views on SQL Server instead of keeping them in your Access application.
Little things such as using % instead of * as wildchars in queries using LIKE in their WHERE clause can also cause strange issues like queries not returning any records.
By the way, I'll post a very good resource Tony has on his own website regarding SQL upsizing: My random thoughts on SQL Server Upsizing from Microsoft Access.
There is also a good and detailed read about things to consider when using SQL Server from Access: Optimizing Microsoft Office Access Applications Linked to SQL Server
YOu can add the SQL Server tables to access as linked tables. Then you will want to start looking at your slowest queries and convert them to stored procs.
Do not use the upgrade wizard in Access to create the SQl Server tables becasue it will make poor choices for datatypes. Do the work yourself to create the scripts, choosing the best datatypes. It takes longer this way, but your database will perform better and you will gain a better understanding of how to do things in SQL Server. You should start right now, learning to do everything through a script and never from the GUI. Best to learn good habits in SQL Server from the start.