Right... I've got a program I'm doing some maintenance on.
Urgh. Even describing it makes me shudder... Right, okay.
Every night, a database running on what we think is SQL Server 2000 hooks up to an Informix database and copies it over into SQL Server.
The Informix/SQL data is accessed by the program I'm maintaining, which then stores some data in a different SQL Server 2000 database. This data should have foreign key constraints on the Informix data, but doesn't.
Further on down the line, data from the SQL database is put back into the Informix/SQL database, and later still, back into the actual Informix database.
Basically, the root of my problem is that there are no foreign or primary key constraints on the non-Informix SQL database. Well, some of the tables have a Primary key on a non-meaningful "ID" column, but those aren't FK'd to any other tables.
My question is: Is it possible to link SQL Server 2000 to the native Informix database in some way, so that I can add foreign key constraints within the SQL database so that SQL Server can only create rows when it can refer to existing rows within the Informix database?
I'll do my best to answer any questions anyone has, but as far as I can tell the reasoning behind these design decisions was genuine insanity, so reasons won't be particularly forthcoming, as I can't work them out, myself...
Yuck!
Bad Luck (on the mess you've inherited)!
Good Luck (with your work fixing the mess)!
Which version of Informix, and what platform (type of machine, o/s) is it running on?
Is there a reason (other than it will break because the data is a mess) that you can't update the Informix schema to enforce the real RI constraints. But you probably need to know how bad the mess is so that you can start the cleanup process. IDS (Informix Dynamic Server) does have 'violations tables' which can be used to track problematic rows of data - 'START VIOLATIONS' and 'STOP VIOLATIONS' are the statements to look for in the Informix Guide to SQL: Syntax manual You might well need to unload and delete the data from one table before starting to load the data with the violations checking enabled.
After clarification, the question seems to be "Can I set up referential integrity constraints on tables in the SQL Server databases that are constrained by (refer to) tables in the Informix databases?"
The answer to that is (sadly):
No
Most DBMS are reluctant to have cross-database referential integrity constraints, let alone cross-DBMS constraints.
The closest approximation would be to have copies of the relevant Informix tables in the SQL Server databases, but that probably adds to the data transfer workload. OTOH, cleaning up the data probably requires that - it might be possible to relax that copying later, once the data is more nearly sane. It depends, in part, on the volatility of the referenced Informix data - how often are rows added or deleted to the referenced tables.
Related
Azure SQL tables require a clustered index and will not accept insertions if one is not present. If one is present LogParser is complaining about a mismatch on the number of columns in the select list vs. the target table.
Is there any way to square this circle? Perhaps embed an expression in LP's select list like '"SELECT DateTime,Thread,Level,Logger,Message,Exception,(select max(id)+1 from loggerTbl)...
It's becoming amazingly difficult to parse plain old azure logs into sql where god intends them to be.
Azure SQL tables require a clustered index and will not accept insertions if one is not present.
That is no longer true. Azure SQL DB v12 no longer has this restrictions. Move your DB to one of the new tiers (Basic, Standard) and your DB will be upgraded to v12.
I'm using MS Access 2013 and I have started learning SQL. I have written my SQL Database (all it does is make a bunch of tables) and I don't want to actually write anything in Access, I just want to bring in my SQL and request the Relationship Tables Diagram because my professor wants this particular diagram. Can someone tell me how to accomplish this? When I try to bring in my SQL it gives me errors saying that it was expecting INSERTS, DELETES, etc. but I don't have any actual data yet. I tried to look it up, but everything on Access and SQL is about making queries and I don't think that is what I'm after.
Your database schema should have the following.
1 - one create database statement
2 - one to x create tables statements
3 - primary keys for the each table
4 - foreign keys to express relationships.
5 - other object when business requirements need them.
http://en.wikipedia.org/wiki/Database_schema
Given this schema, the TSQL file can be loaded into any good modeling tool like ERWIN to generate a diagram.
If you want to do it from MS Access, you can. Behind the scenes, MS Access does support SQL in the query builder and you can use the table diagram window.
On the other hand, you can link MS Access to a SQL database (all tables) and still use the table diagram window.
I don't know if I am using the correct terminology here.
I want to recreate the tables of a local database on my computer on another one. I do not care about duplicating the data stored, but just the tables, their relationships, constraints etc.
I have been using Microsoft SQL 2012. Is there a way to generate the SQL code that defines my tables. (What I would have typed to set up my tables had I not done it graphically)
I am developing a Grails-application which uses several databases, others are read-only and 1 is the app's sort of a "main db". Additionally there are multiple environments: dev, qa, prod. qa is used for release-testing and is identical to prod.
Always before release-testing I need to overwrite the "main" qa-database with "main" prod-database. I don't have other than SQL-user access to the server running MS SQL instance.
What I need is the magic that drops everything in qa-database without dropping the database itself and imports everything from the prod-database. Databases contain a lot of foreign key constraints.
How to achieve the aforementioned?
P.S.
I did this on MySQL but now we've migrated to MS SQL. My MySQL-script goes somewhat like this (pseudo):
SET foreign_key_checks = 0;
-- Drop all tables..
SET foreign_key_checks = 1;
-- Import prod-dump to DB..
You shouldn't do this in straight T-SQL.
You really should use something like SMO Scripting in .NET to export objects in this way. There is NO clean way to do what you are asking in pure SQL code.
There are too many variables to account for if you plan to just build dynamic SQL from system tables, which is the only way to approach this in T-SQL.
I think the the tool "xSQL Data Compare" exactly matches your requirements. You will need "sa" access at least for the qa-DB though.
I had a notion to use a database column of type replication ID, but have since changed my approach and want to use this column for another purpose.
However, I'm unable to use SQL to drop the column to remove it from my database.
My SQL is:
ALTER TABLE foo_bar DROP COLUMN theFoo;
However, I get a "syntax error" and I'm assuming this has something to do with this column being a replication ID.
I'd rather not download the file and edit it directly using the MS Access application, but not sure if that's my only recourse.
Thanks so much in advance.
Regards,
Kris
If you have access to the database in a command shell, Michael Kaplan's Replication System Removal Fields utility should do the trick. However, I've found that in some circumstances, it's unable to do the job. Also note that the utility will only work with a Jet 4 format database (MDB), not ACE format (ACCDB).
If all else fails, you can recreate the table structure and append the existing data to it. That can get messy if you have referential integrity defined, though, but it will get the job done, and likely most of it is scriptable (if not all possible using just DDL).
Here is a link that may help you, I had a similar idea but when browsing the web found this
AccessMonster - Replication-ID-Field-size
EDIT: Well I don't have much time but what I was thinking of first was if you could alter the column to make it different (not a replication ID) and then drop it. (two separate actions). But I have not tested this.