This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Is there a way or if not could there be a way to get the create/change script that LS uses when it updates a database. This is something that OA does. Can/could LS? |
|
|
This is a feature we could add pretty easily (and in fact have done a proof of concept internally), but our concern is that the scripts we could generate today might tempt incorrect usage. For example, if a developer runs an Update Database against his local database, and captures the change script, that does not guarantee that the resultant script would be correct for other devs to use against their local databases, or against a production database, because those other databases might be in a different baseline state. Nor do we currently generate rollback scripts in case anything goes wrong. Also, given our present internal architecture, we would not be able to easily produce the scripts independently of running them: that is, you would have to allow us to update your local database, and get the scripts as a by-product, rather than us just generating the scripts and leaving them for you to review and run later. Given those comments, would this feature still be of interest to you? If so, I will raise this with the rest of the team and see how they feel about enabling this feature. By the way, we are hoping to add a more structured migrations feature in 3.0, which will improve granularity, support rollback, etc. |
|
|
"you would have to allow us to update your local database, and get the scripts as a by-product" That was what I was looking for, a record of the changes LS has made after it has made them. A warning at the top of the script similar to the one VS has should deter incorrect usage. eg. VS SQL designer gives you /* To prevent any potential data loss issues, you should review this script in detail before running it outside the context of the database designer.*/ |
|
|
Hello Daren, I have now committed this feature and it will appear in nightly builds dated 28 Feb 2009 and above, available after about 1430 GMT. To activate capture, select Log SQL in the "Update Database" dialog. At present it does not remember your preference so you will need to remember to do this each time. An additional note: I realised while testing this that some of our update scripts will not be runnable directly. An example is if you are deleting multiple columns out of SQL Server. Because of the way SQL Server handles constraints, before we delete a column, we run some SQL to drop any constraints on that column. This SQL declares two variables, which have hardwired names (because they were previously used only as local variables within a single delete operation). So if you are deleting multiple columns, the captured SQL will end up declaring the same variable multiple times. I have injected comments into the logged SQL to help you more easily locate the boundaries between "chunks" of SQL so you can run them independently as the designer originally did. We would welcome your feedback on this or any other aspects of the feature, and of course please let us know if you run into any problems. |
|