marrowyung
asked on
How to not create the MySQL table if it exists
Dear all,
Right now if I generate the MysQL table create statement it don't give me the statement that to check the existence of table before it creates.
how to do this, let have an example, how to ignore the following create table statement if it exists already.
Right now if I generate the MysQL table create statement it don't give me the statement that to check the existence of table before it creates.
how to do this, let have an example, how to ignore the following create table statement if it exists already.
[/CREATE TABLE `QRTZ_CALENDARS` (
`SCHED_NAME` varchar(120) NOT NULL,
`CALENDAR_NAME` varchar(200) NOT NULL,
`CALENDAR` blob NOT NULL,
PRIMARY KEY (`SCHED_NAME`,`CALENDAR_NAME`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
as I will do this too:
any way to ignore field if it is there or just replace it as we might change this type later on ?
CONCAT( 'ALTER TABLE Audit_info.DBAudit_', tablelist,' ADD TriggerAction VARCHAR( 10 ) NULL,
ADD Action CHAR( 10 ) NULL AFTER TriggerAction ,
ADD ActionDate DATETIME NULL AFTER Action ,
ADD ActionBy VARCHAR( 50 ) NULL AFTER ActionDate ;');
any way to ignore field if it is there or just replace it as we might change this type later on ?
ASKER
we need this as it will complain:
as it found the same column with the same name.
MySQL Database Error: Duplicate column name 'Action'. Add a differentiating column alias.
as it found the same column with the same name.
>>any way to ignore field if it is there or just replace it ...?
the grand purpose of this is to audit the source tables.
If you drop columns then you lose the audit data of that column.
>>" as we might change this type later on "
for this you would have to compare meta-data of each existing column (to determine if it has changed or not).
These are your decisions to make.
-----------
I think quite some time ago I suggested finding something that was tested and proven in this field rather than building from scratch. That advice still stands in my opinion.
the grand purpose of this is to audit the source tables.
If you drop columns then you lose the audit data of that column.
>>" as we might change this type later on "
for this you would have to compare meta-data of each existing column (to determine if it has changed or not).
These are your decisions to make.
-----------
I think quite some time ago I suggested finding something that was tested and proven in this field rather than building from scratch. That advice still stands in my opinion.
ASKER
"I think quite some time ago I suggested finding something that was tested and proven in this field rather than building from scratch. That advice still stands in my opinion. "
where is it ? please show me.
"If you drop columns then you lose the audit data of that column."
yes, we will tell developer about this. so we have a good reason to NOT removing the audit column.
But how about field type change? still lost all data?
"for this you would have to compare meta-data of each existing column (to determine if it has changed or not)."
so can't do any alter/replace statement directly on the schema ?
where is it ? please show me.
"If you drop columns then you lose the audit data of that column."
yes, we will tell developer about this. so we have a good reason to NOT removing the audit column.
But how about field type change? still lost all data?
"for this you would have to compare meta-data of each existing column (to determine if it has changed or not)."
so can't do any alter/replace statement directly on the schema ?
>>But how about field type change? still lost all data?
well this is really hard to answer
Most likely, no loss.
e.g. change column from decimal(12,4) to decimal(18,5)
But, on occasions, big problems!
e.g. change column from nvarchar(10) to date
in this example you may have started keeping dates in YYYY-MM-DD as a string but decided that was silly and to go for date instead. Trying to automate such a dramatic shift of data type would be "hard" and data loss is likely.
well this is really hard to answer
Most likely, no loss.
e.g. change column from decimal(12,4) to decimal(18,5)
But, on occasions, big problems!
e.g. change column from nvarchar(10) to date
in this example you may have started keeping dates in YYYY-MM-DD as a string but decided that was silly and to go for date instead. Trying to automate such a dramatic shift of data type would be "hard" and data loss is likely.
ASKER
ASKER
Open in new window