Link to home
Start Free TrialLog in
Avatar of marrowyung
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.

[/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;

Open in new window

ASKER CERTIFIED SOLUTION
Avatar of PortletPaul
PortletPaul
Flag of Australia image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Example
CREATE TABLE IF NOT EXISTS `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
;

Open in new window

Avatar of marrowyung
marrowyung

ASKER

as I will do this too:

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 ;'); 

Open in new window


any way to ignore field if it is there or just replace it as we might change this type later on ?
we need this as it will complain:


MySQL Database Error: Duplicate column name 'Action'. Add a differentiating column alias.

Open in new window


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.
"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 ?
>>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.