The forum will experience an outage sometime between February 10 at 7:00pm EST and February 12 at 11:59 EST for installation of security updates. The actual time and duration of the outage are unknown but attempts will be made to minimize the downtime. We apologize for any inconvenience.

Can we for a specific session or transaction block set automatic commit(side effect) to off? Or is there a "ddl in tran" equivalent in ASA.

asked 15 Jan '13, 07:30

cmila's gravatar image

accept rate: 0%

What are you trying to achieve?

As documented here, most SQL Anywhere DDL statements do an automatic commit as side effect, so they close a transaction by design.

When you are trying to execute DDL from within a stored procedure, there are certainly alternatives to do so. Say, if you need to create several objects in one transaction, have a look at the CREATE SCHEMA statement which allows to group several DDL statements in one transaction (or at least it rollbacks all statements when one statement fails, so I assume it just uses one single transaction...).

permanent link

answered 15 Jan '13, 08:26

Volker%20Barth's gravatar image

Volker Barth
accept rate: 32%

Hi Volkver,

Thanks for your answer. One of the customer software deliveries is an automatic database Deployment tool for the Sybase database production environment with an ASA 12.0.1 database server. their intention is that all their database increments (script files) are deployed one by one by the automatic Deployment tool. The increment is deployed within a transaction mechanism that is supported by the Deployment tool. A usual single script files contains a set of both DDL and DML statements to be able to do a complete functional increment. Normally each script would be committed, but when a script fails the whole increment should be rolled back till the previous committed script/increment. The overall deployment should also be stopped when this exception event occur. So far it only works for the DML SQL statements in the scripts but NOT! for the DDL statements in the script. As you understand they want both the DDL and DML statements of the script to be rolled back when something fails.

They also tried to switch the 'Chained' database option to get it done but it makes no difference when it is on or off. They created this type of Deployment for other database vendors, that worked for both the DML and the DDL statements. Please would you advise on what can be done to make this work? Do you know if there is a work-around for this issue?

(15 Jan '13, 08:37) cmila
Replies hidden

There are no workarounds. Accept reality as it is.

(16 Jan '13, 06:18) Dmitri

A common method for SQL Anywhere to guarantee that a database schema upgrade is either successfully completed or completely rolled back would be to do a database backup just beforehand - and restore that in case an error is thrown during the upgrade.

That does work well with embedded databases. It may not work well in an "actively used multi-user database" - however, a script with a bunch of (by definition blocking) ALTER TABLE statements that have to be rolled back (or undone) lateron in case of an error won't make concurrent users happy, either...

(16 Jan '13, 07:10) Volker Barth
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 15 Jan '13, 07:30

question was seen: 1,190 times

last updated: 16 Jan '13, 07:11