I'm distributing a database but I have two tables with foreign keys references to the other database in other server. I have already searched and found that I can't make a foreign key referring to a table in another database in other server. But, how can I resolve this problem? Creating views?
In the instance that needs to refer to "the other server", introduce "the other server" as a linked server and then use INSTED OF triggers to validate the FK constraints.
Related
Initial question (solution comes afterwards):
I have the following challenge: I have an Oracle database where a software (Infor Supplier Exchange) once created tables and filled them with data. This db shall be migrated to SQL Server, then an upgrade of the Infor software shall be executed with the migrated data.
A colleague of mine already used a script by Microsoft to migrated the Oracle db to SQL Server which is now available for me. Even though the "Keep Identity" flag was set, no primary key in the new db has its Identiy (autoincrement) set - but that is needed by the Infor software to add data later.
I found a way via SSMS to change the Identity (as well as its seed) for each relevant db table: Right-click on the table, design, change the "Identity Specification" manually. But I have over 300 tables: The effort would cost hours (and sanity).
I also found out that I can use SSMS's "export data" task. You have to know that the Infor software provides a db installer which creates all necessary tables, keys, identity properties, etc. with an EMPTY database. So I can basically export the data from the "Oracle migrated old db" to the "Infor prepared new db" since they (should) have the same table names, keys etc. - except the Identity property and the user data.
In the export data task you can check "Enable identity insert". The problem is that this SSMS feature aborts when it processes a table with foreign keys where the referenced table does not exist, yet. So I could go through the old db again, execute the "copy data" task for all tables without primary keys first, then try the remaining tables until all data is copied to the new db. But this is again much effort since I have to go back on every error or check all contraints beforehand.
Do you have a better approach? Is it possible to copy data from db A (with 300+ tables) to db B (with the same table structure), hoping that a tool solves the correct order of tables because of their foreign key constraints?
If you have questions on the issue I can explain in more detail. Thanks in advance.
Solution:
I solved the task by disabling constraints and triggers temporarily. The steps are:
EXEC sp_MSForEachTable "ALTER TABLE ? NOCHECK CONSTRAINT all"
sp_msforeachtable "ALTER TABLE ? DISABLE TRIGGER all"
EXEC sp_MSForEachTable "DELETE FROM ?"
I had to clear the target database's tables since they are filled with some sample data by the Infor installer. The data export task can append rows or can try to remove existing rows (with same primary keys). But this uses TRUNCATE internally which doesn't work with foreign key contraints, even when they are disabled by the above command.
Next: Execute the SSMS database task "Export data". Ignore datatype conversion errors (some types differ from Oracle-Migration to target SQL schema, like varchar to nvarchar which I checked and judged as not critical).
exec sp_MSForEachTable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT all"
sp_msforeachtable #command1="print '?'", #command2="ALTER TABLE ? ENABLE TRIGGER all"
Using the vendor's SQL Server database schema and loading the data yourself is typically the correct approach for migrating to SQL Server with packaged software. But there may be additional guidance available from the vendor.
Instead of trying to load the tables in an order that is compatible the foreign key constraints, which is not always even possible, disable all the foreign keys before loading the database and re-enable them after. See eg Temporarily disable all foreign key constraints
I am using SQL Server database and Django. I have a Database named as Person Database and Other database as Student Database. In Person database I created models, but in Student database there are no models because the tables and data are already existing. So I am getting data of Student database using Pyodbc. Now I am creating a new model in Person database where I need to create a foreign key for student database. Can anyone help me out how to do it.
You cannot create a Foreign Key relation in between tables of different databases. Foreign Key relations can only be created between tables of the same database. There is a workaround on this, although it is not recommended. Please refer this answer.
Modeled numerous tables for a database. Each table has got its primary key and Foreign Key(s). But when i'm generating DDL scripts for the tables, foreign key constraints are unavailable even if model diagram shows constraints it has.
As its solution i've already tried out all those check marks available we could use while generating DDL.
What i believe i must have left any other configuration or followed incorrect sequence of steps for the same.
Possibles solutions will be welcomed. Else i will have to add constraints manually which shouldn't be the standard if you're using a dedicated tool.
See the images for more clarification
i have two sites that sell the same products (same database structure and everything). One of them has recently had all its products updated and we need to take the data from three tables on the updated site and override those same three tables on the out of date site. is there a way to do this is Sql Server MS? ive tried truncating the tables in sql to then do a "insert into db1table select * from db2table" but i just get errors from the foreign keys. Someone showed me a trick a while in visual studio enterprise for comparing data where vs spits out a .sql file you can run to update your table but i only have vs professional 2010 and this doesnt seem to be part of the package.
Assuming you have the same foreign key constraints in both the databases and if foreign key constraints are the only issue -
why don't you just
1) Disable all the foreign keys
2) Load the data
3) Enable all the foreign keys
I come from Oracle background, it should not be very hard to disable/enable all foreign key constraints using a script at one go in SQL Server too.
I've just come across something disturbing, I was trying to implement transactional replication from a database whose design is not under our control . This replication was in order to perform reporting without taxing the system too much. Upon trying the replication only some of the tables went across.
On investigation tables were not selected to be replicated because they don't have a primary key, I thought this cannot be it is even shown as a primary key if I use ODBC and ms access but not in management studio. Also the queries are not ridiculously slow.
I tried inserting a duplicate record and it failed saying about a unique index(not a primary key). Seems to be the tables have been implemented using a unique index as oppose to a primary key. Why I do not know I could scream.
Is there anyway to perform transactional replication or an alternative, it needs to be live (last minute or two). The main db server is currently sql 2000 sp3a and the reporting server 2005.
The only thing I have currently thought of trying is setting the replication up as if it is another type of database. I believe replication to say oracle is possible would this force the use of say an ODBC driver like I assume access is using hence showing a primary key. I don't know if that is accurate out of my depth on this.
As MSDN states, it is not possible to create a transactional replication on tables without primary keys. You could use Merge replication (one way), that doesn't require a primary key, and it automatically creates a rowguid column if it doesn't exist:
Merge replication uses a globally
unique identifier (GUID) column to
identify each row during the merge
replication process. If a published
table does not have a uniqueidentifier
column with the ROWGUIDCOL property
and a unique index, replication adds
one. Ensure that any SELECT and INSERT
statements that reference published
tables use column lists. If a table is
no longer published and replication
added the column, the column is
removed; if the column already
existed, it is not removed.
Unfortunately, you will have a performance penalty if using merge replication.
If you need to use replication for reporting only, and you don't need the data to be exactly the same as on the publisher, then you could consider snapshot replication also