I have exported a number of Microsoft Access database tables to a SQL Server 2012 using ODBC. Subsequently, I have linked to the data sources by creating linked tables.
Now here's the issue.
When I verify the tables in SQL Server itself, I notice only the database tables, columns and their respective datatypes are present. There are no key or indexes to be found. Still, in my Access database they were all defined. Also, I noticed that Access requests to choose a field(s) that uniquele identify each record to ensure data integrity and to update records. These then become the Primary Keys I understand, but why not use the PK that are already present?
What would be the easiest and most efficient way to also migrate the other field properties like indexes, keys, constraints? As otherwise, I would need to define all those manually and this would be very time-intensive.
Many thanks for your help!
As you have discovered, the keys and indexes and not copied over if you simply export an Access table to SQL Server using External Data > Export > More > ODBC Database:
However, the indexes, keys, and relationships are copied over to SQL Server if you use the "Upsizing Wizard", which is invoked via Database Tools > Move Data > SQL Server:
Note: The "Upsizing Wizard" was removed from Access 2013, so users of Access 2013 (and newer) will need to use the "SQL Server Migration Assistant for Access" instead. For more information look here.
Related
I would to copy a SQL Server 2012 database from one server to another with the least amount of manual work and without doing a restore or attach database because I don't have access to the source server or backup files.
I would like to have a copy of all the objects and data. This includes tables with primary (including identity designation) and foreign keys, views, stored procedures, constraints and triggers.
If I use SSMS, I have to use a combination of data imports and scripting the objects. One issue with this is that I have many tables and manually enabling identity inserts is a hassle. Maybe one way is to use a diff tool to do all this work for me if possible or find a way to script the identity properties across the tables.
Is there a simpler more straightforward way to copy a database?
Replication. There are different types. Transactional will keep your copy updated with any changes. Snapshot will not, etc.
Without access to the server, I am not sure what you can do at all?
I have a lot of views and tables connected in Microsoft SQL Server. I want to check all the useless columns I have in the native tables. Is there a way to perform an automatic check if a column in a table is used or not in other tables?
Create a database diagram in SQL Server Management Studio. From here you can analyze how the tables/columns are related or not. Info here
Do a business model analysis and see which values are used, which are deprecated and start from there.
If you do any changes on the database, these changes have to be projected in any code connecting to that database.
Do not remove columns in tables just by looking at a database diagram. You would destroy any object-relational mapper.
I connected a sql server through ODBC and lined sql tables. I manually created my relationships in my database but, when I do that, my other tables are not editable. My drop downs I created won't allow me to select it or my text box doesn't let me type in it.
How am I supposed to create a relationship so I can use Access as a front-end to enter in data into the database?
If you are linking to tables that exist already in SQL Server, then you don't need to worry about creating relationships in Access.
If you want to edit data in the SQL Server tables, make sure that you have a primary key on each table, and if possible a field with at "timestamp" data type.
I'm running into a problem when accessing a SQL Server table from an Oracle setup via ODBC.
I can access 90% of the tables absolutely fine, but there's a few tables that have a name that's longer than 30 characters. Whenever I try to interact with the table (describes, selects, etc) Oracle throws an "identifier too long" error and gives up.
Is there a way to coax Oracle into playing nice with the SQL Server tables?
Assuming that we are talking about an Oracle database that has a database link created to a SQL Server database via Heterogeneous Services, you would need to write code using the DBMS_HS_PASSTHROUGH package to interact with the tables in question. You'd also need to use this package if you have tables where there are column names that are not valid Oracle identifiers.
I'm working on the old C++ MFC project (> 10 years old). Database application works with migrating from MS Access (2007) to MS SQL Server (2008 R2) and I faced some hurdles on the way. For exporting data I used MS SQL Management Studio ("Import" option in the menu)
As it's known, there are some differences in data types between Access and MS SQL. That turned into some troubles.
Columns "ID" from Access (Autonumber, not NULL, primary keys) become just usual columns in SQL Server (int, not NULL and without any autoincrement). So I got lots of mistakes while inserting new rows into the tables.
Yes/No type in Access (-1/0; NULL is not allowed) becomes bit (1/0/NULL), logic of work shouldn't be broken as in the most of the places it is comparision of being not equal to 0:
query.Select()
.Buff("ID", &code)
.FromS("%Table_Name%", NULL)
.Where().Str("Aktiv <> 0")
.Execute();
Looking for a solution I saw the advice to use SSMA (SQL Server Migration Assistant) for Access. It's much better and more intellectual as it recreated primary/foreign keys, created CHECK's, indexes. But unfortunately lots of the FOREIGN KEYs' action Update/Delete operation become not Cascade but No Action. Warning message after schema import:
FOREIGN KEY constraint "Reference77" on MS Access table %Table1% may cause circular or multiple cascade paths. The cascade option from table %Table2% to table %Table1% was set to No option in SQL Server.
And that's not a surprise application gets some errors while deleting objects, though it was all OK in Access. For testing I selected one delete operation (in application) which got errors. I watched error messages and changed No Action -> Cascade for the involved FOREIGN KEYS via SSMS (SQL Server Management Studio). After that delete operation in the application succeeded.
My questions are:
Am I right I need only to change No Action -> Cascade for the FOREIGN KEYs to get the database application can work completely proper? Or there can appear another issues I don't know?
How can it be realized? I would like it to be a good solution for applying it on clients' SQL Servers.
Thanks for help, I really appreciate it!
Thanks for your answer. The solution for my problem is ... exporting data directly from Access (2010) to SQL Server.
I tried:
"SQL Server Import and Export Data", result - copying of only data from Access database, no any primary oк foreign keys, no transformation of autonumber to a column with IDENTITY and autoincrement.
SQL Server Migration Assistant for Access, result - a lot of foreign keys lost CASCADE property for update/delete operations. But all another things are OK.
Access 2010! Database Tools -> SQL Server -> ... using wizard -> all is OK with schema and data. Application works fine with the SQL Server database imported from Access.
So direct export from Access to SQL Server gave the required result.
Probably, but you will still need to test.
For a reusable solution, I would script the database that SSMA created (checking that all the types and foreign keys are correct). Having this script you can create an empty SQL Server database on any number of servers.
To populate these databases I'd use an Integration Services package. It's very easy to create by using Import wizard: going thru all the steps, but saving the package instead of running it immediately. Then you can open this package and edit it (adding data conversions or any other logic if necessary).