I have a mysqldump file created from an earlier version of a product that can't be imported into a new version of the product, since the db structure has changed slightly (mainly altering a column that was NOT NULL DEFAULT 0 to UNIQUE KEY DEFAULT NULL).
If I just import the old dump file, it will error out since the column that has default values of 0 now breaks the UNIQUE constraint.
It would be easy enough to either manually alter the mysqldump file, or import into a temp table and change it, then copy to the new table. However, is there a way to do this programatically, so it will be repeatable and not manual? (this will need to happen for many instances of this product).
I'm thinking something like disabling key constraints for the import, then setting all values that = 0 to NULL, then re-enabling the key constraints?
Is this possible? Any help appreciated.
Yes.
SET UNIQUE_CHECKS=0; Turns off Unique Key Constraints
SET FOREIGN_KEY_CHECKS=0; Turns off Foreign Key Constraints
Import file
Update 0 to Null
SET UNIQUE_CHECKS=1 turns back on
SET FOREIGN_KEY_CHECKS=1 turns back on
You could just use sed and modify the dumpfile in an automated, repleatable way.
sed s/NOT NULL DEFAULT 0/UNIQUE KEY DEFAULT NULL/g
or something like that.
Related
In HSLQDB v 2.3.1 there is a create type clause for defining UDTs. But there appears to be no alter type clause, as far as the docs are concerned (and the db returns a unexpected token error if I try this).
Is it possible to amend/drop a UDT in HSQLDB? What would be the best practice, if for example I originally created
create type CURRENCY_ID as char(3)
because I decide I'm going to use ISO codes. But then I actually decide that I'm going to store the codes as integers instead. What is the best way to modify the schema in my db? (this is a synthetic example, obviously I wouldn't use integers in this case).
I guess I might do
alter table inventory alter column ccy set data type int
drop type CURRENCY_ID
create type CURRENCY_ID as int
alter table inventory alter column ccy set data type CURRENCY_ID
but is there a better way to do this?
After trying various methods, I ended up writing a script to edit the *.script file of the database directly. It's a plain text file with SQL commands that recreates the DB programmatically. In detail:
open db, shutdown compact
Edit the script file: replace the type definition, e.g. create type XXX as int to create type XXX as char(4)
For each table, replace the insert into table XXX values (i,...) with insert into table XXX values('str',...). This was done with a script that had the mappings from the old (int) value into the new (char) value.
In my particular case, I was changing a primary key, so I had to remove the identity directive from the create table statement, and also I had to remove a line that had a alter table XXX alter column YYY restart sequence 123.
save and close script file, open db, shutdown compact
This isn't great, but it worked. Advantages :
Ability to re-define UDT.
Ability to map the table values programmatically.
Method is generic and can be used for other schema changes, beside UDTs.
Cons
No checking that schema is consistent (although it does throw up errors if it can't read the script).
Dangerous when reading file as a text file. e.g. what if I have a VARCHAR column with newlines in it? When I parse the script file and write it back, this would need to be escaped.
Not sure if this works with non-memory DBs. i.e. those that don't only have a *.script file when shutdown.
Probably not efficient for large DBs. My DB was small ~ 1MB.
The database that I am tasked with fixing has a table with an identity column/PK that has a datatype of BigInt. This causes problem with the Access front end in that a datasheet to this linked table will not allow edits to the records. (This is a known issue with ODBC drivers and Access)
The table's Id column should never have been created as a bigint in the first place but that is a moot point now. I need to convert or recreate this column with a datatype of int, without losing the existing data.
There are ~2 million records in this table.
There are an unknown number of apps and Access apps that access this table so I am trying to do this as smoothly/stealthily as possible since the likelihood of finding all of those apps and modifying them before I make the change is slim.
Any thoughts or ideas?
I'm assuming the IDENTITY column is your PRIMARY KEY, and it's probably clustered :) MY advice below is based on those assumptions.
If you've only got a few indexes on the table, and the PRIMARY KEY is only referenced by a few FOREIGN keys, you should be able to change the datatype by:
Dropping any nonclustered indexes which contain the IDENTITY value.
Dropping the FOREIGN KEY constraints which point to the PRIMARY KEY.
Drop the PRIMARY KEY
ALTER TABLE tablename ALTER COLUMN columnname INT;
REcreate the PRIMARY KEY
Re-enable the FOREIGN KEY constraints with CHECK.
Recreate your nonclustered indexes.
As RBarryYoung pointed out, a lot of this can be scripted out by the SSMS GUI (if it's configured to allow saving changes), but the difference is that the GUI will create a temporary table, move your data, rename the new table to the old name, and drop the original.
Here's how to do it from Management Studio(SSMS):
First, make a backup copy of your database. If you make a mistake, or something unexpected happens, the easiest way to fix it is to restore from backup.
In the SSMS Explorer Pane, navigate to the table, then right-click on it and click "Design".
Select the Identity column's row and change it's datatype to "INT".
Save your changes, ignore the warning.
If you need a script instead, then replace step (4) above with:
Click the Script Changes button. Ignore the warning and then copy the script into you paste buffer. Make a new query window and paste the script into it. Then close the design window, cancelling any changes.
As Stuart Ainsworth points out, in later versions of SQL Server, it may prevent you from doing this, with a warning about "Dropping a Table". To fix this in SSMS, click the Tools..Options menu entry, then go to the "Tables and Designers" pane under "Designers" and uncheck the "Prevent saving changes that require table recreation" option.
I have an issue related to data in sql server. In my database some of the constraint were not enabled i.e. they were not checked , After some time working on it we found this issue that a parent rows can be deleted without deleting child, which was an issue. I enabled all the constraint in the database using query
ALTER TABLE tbl_name CHECK CONSTRAINT ALL
above query was executed on all the tables of that database without any error . But my concern is whether it will work or not , if it will work on the existing data then what will happen to that data whose parent table data has been deleted.
I want to know is there any way such that I can validate such data data whose parent record doesn't exist in the entire database. There are about 270 constraint containing FOREIGN KEY AND UNIQUE KEY . I don't want to go for manual option.
Please help me out.
ALTER TABLE tbl_name CHECK CONSTRAINT ALL
only re-enables the constraints. Importantly, the constraints are not checked against the existing data in the database (nor are they trusted by the optimizer). If you want that to occur, you need to specify WITH CHECK as well:
ALTER TABLE tbl_name WITH CHECK CHECK CONSTRAINT ALL
(And yes, the word CHECK appears twice)
If you execute this, and there are orphaned child rows (or other invalid constraints), then the ALTER TABLE will fail with an error message. There's nothing SQL Server can do to fix this issue - it's for you to decide whether to a) remove the orphaned rows, or b) to re-create, in some manner, a suitable parent row for them.
You can also add the 'ON DELETE CASCADE' code to the end of foreign keys to prevent orphaned child rows from persisting.
This is more of a 'better practice' going forward than a solution, but I believe Damien_The_Unbeliever has answered your main question.
I've got a new website moved to my server. This website uses PHP and MySQL, and is built very poorly.
The problem is - it needs non-null values inserted into new records where ever I don't specify a value, though the default value is null.
I've been told it has been done on the previous server, but they have no idea how. I'd be glad to receive some help on this.
You could update the default values of the fields of your database to prevent problems using:
ALTER TABLE `table` ALTER `field` SET DEFAULT 'value'
More information on ALTER TABLE for specific fields and parameters can be found in the documentation.
You need to add default values for the columns, either recreate the tables with defaults or alter the table definitions.
http://dev.mysql.com/doc/refman/5.1/en/alter-table.html
http://dev.mysql.com/doc/refman/5.1/en/create-table.html
I wanted to modify a column in a sql server 2005 table to IDENTITY(1,1)
Incidentally this table is empty and the column to be changed is a primary key.
This column is also a foreign key for two other tables.
After googling I found that you cannot use Alter table syntax to modify a column and make it an indentity column.
Link #1 : How do I add the identity property to an existing column in SQL Server
Link #2 : Adding an identity to an existing column -SQL Server
I ended up checking the dependent tables (2 of them) removing the foreign keys (generated the script from SSMS) then dropping the main table then re-creating with identity. (could try the rename option here as well)
Then re-created the foreign keys for the earlier dependent two tables.
But all this was manual work, any scripts or SPs out there to make this easier.
Ideally all these steps would be done by such a script/tool/utility:
Check dependent tables keys
Generate Create and drop foreign key scripts for this
Generate create script for the main table
drop the main table (or rename the table if the table has data)
re-create the table with identity column enabled
re-create foreign keys
You can use SSMS to generate a script (Edit a table, save script), but otherwise it's a manual process as you identified.
The SSMS scripts will pick up dependencies etc. For this kind of work, I tend to use SSMS to generate a basic script, pimp it a bit, run it carefully, then use a comparison tool (such as Red Gate compare) to generate a safer version.
Edit: The SSMS error is not an error, it's a safety check that can be switched off
(This is merely a follow-up to gbn's post with more details -- it isn't all that easy to figure this stuff out.)(
It isn't impossible to write a utility to do this, just very complex and very hard. Fortunately, Microsoft has already done it -- its called SSMS (or SMO?). To generate such a script:
In the Object Explorer, drill down to the database and table that you want to modify
Right click and select Design
Make the desired changes to the one table in the design screen. It's reasonably intuitive.
To add/remove the identity property, select the column in the upper pane, and in the lower pane/"Column Properties" tab, expand and configure the settings under "Identity Specification".
To generate a script to implement all your changes, incorporating all the dependent key changes, click on the "Generate Change Script" toolbar button. This is also an option under the "Table Designer" menu.
I also do this to generate scripts (that I later modify--SSMS doesn't always produce the most efficient code.) Once done, you can exit out without saving your changes -- leaving you a DB you can test your new script on.
drop the pk and build the same datatype column
copy the data of the column which you want to set identity to the new column.
drop the old column
reset primary key
ALTER TABLE UserRole
DROP CONSTRAINT PK_XX
ALTER TABLE XX
ADD newX int not null identity(1,1) primary key
update XX set newX = oldX
alter table XX
DROP COLUMN oldX
this is the simplest way to set identity column.
if you don't want to use the long generated script.