A trigger is a small function stored inside your database that gets triggered on a event in your database. Like, the moment you add or update a row in your table.

For versioning we need 2 things:

- a few extra fields in your table
- a copy of the table structure of the table you want versioning turned on

First, let’s define 2 extra fields:

- enuVersionStatus (ENUM) = ‘INSERT’, ‘UPDATE’, ‘DELETE’
- tsVersionStatus (timestamp) = current_timestamp & on update current_timestamp

enuVersionStatus is defined as a enumerable field that holds the state of the data
tsVersionStatus is defined as a timestamp and holds the timestamp when the data has been edited

Now we copy the entire structure of our table to a log, or history table. Let’s just append a “_log” to this table and remove any indexes or auto_increment statements. And lastly we create a new trigger:

DELIMITER $$
CREATE TRIGGER myTable_Trigger
BEFORE UPDATE ON myTable
FOR EACH ROW
BEGIN
INSERT INTO myTable_log (SELECT * FROM myTable WHERE id = OLD.id);
END$$

What the trigger does is very simple. Just before doing any update on the table, the “old” entry is being written into the log table. The data in myTable holds the live data and the myTable_log holds all the old entries.

It seems that Eclipse made some big changes in Eclipse 3.5 (Gallileo). So the Flex Builder 3 plug-in would not install correctly. After surfing the internet for answers I found a post about the link-file inside the links folder. It seemed that I had to edit this file in order to get it going.

Almost!

Not only do you have to edit the file links/com.adobe.flexbuilder.feature.core.osx.link from /Applications/Adobe Flex Builder 3 Plug-in to path=/Applications/Adobe Flex Builder 3 Plug-in
But this only works with the Cocoa version of Eclipse!

Finally, the working setup:

• Eclipse PDT Cocoa version
• Flex Builder 3 plug-in
• Changes to the links/com.adobe.flexbuilder.feature.core.osx.link file as described above

I had to change some of the features I had in mind. But it is still enough to get a backup done. So first, let’s see what we have to do on our VMWare Infrastructure Server. The custom fields we defined earlier have to be changed as follows:

0_BackupEnabled (”Yes” to enable)
1_BackupAccess (nbd, san, …)
2_BackupRotation (days to store the backup)
3_BackupCurrentStatus
4_BackupLastStatus
5_BackupSize (in kb)
6_BackupTime

So after updating the custom fields as described we can use the finished script to enable the backups by editing the custom fields for every virtual machine you want to backup. It’s quite easy and you can enable the backup of a virtual machine after creating a new one. No need to edit configuration files on the backup server, or to add new backup schedules.

The finished script can be downloaded here: http://idisk.mac.com/polysign-Public?view=web
(Folder “code”, Filename: vcbackup.txt)

Just edit the configuration in the script file and you are good to go. Have fun!