I have sooo many row level triggers in my ASA(9.0.2)
Database and I have heard that row level triggers won't run
in ASE. Is this true? I am not familiar with ASE.
The problem is that we have an upcoming project that would
require us to migrate ASA structure to ASE. So, if i just
right-click then change to T-SQL my row level triggers and
apply it to ASE would this be effective?
And would it run as effectively as my triggers in ASA?
From: Chris Ceniza
Subject: ASA to ASE Issue
X-Mailer: WebNews to Mail Gateway v1.1t
Date: 21 Sep 2005 00:02:53 -0700
X-Trace: forums-1-dub 1127286173 10.22.241.41 (21 Sep 2005 00:02:53 -0700)
X-Original-Trace: 21 Sep 2005 00:02:53 -0700, 10.22.241.41
Xref: forums-1-dub ianywhere.public.general:4787
Article PK: 8541
Subject: Re: ASA to ASE Issue
From: David Fishburn <firstname.lastname@example.org>
Organization: iAnywhere Solutions
User-Agent: Xnews/06.08.25 Hamster/126.96.36.199
Date: 21 Sep 2005 06:13:26 -0700
X-Trace: forums-1-dub 1127308406 188.8.131.52 (21 Sep 2005 06:13:26 -0700)
X-Original-Trace: 21 Sep 2005 06:13:26 -0700, vpn-concord-104.sybase.com
Xref: forums-1-dub ianywhere.public.general:4788
Article PK: 17424
Chris Ceniza wrote in news:email@example.com
CC> I have sooo many row level triggers in my ASA(9.0.2)
CC> Database and I have heard that row level triggers won't run
CC> in ASE. Is this true? I am not familiar with ASE.
Correct, ASE only has statement level triggers.
CC> The problem is that we have an upcoming project that would
CC> require us to migrate ASA structure to ASE. So, if i just
CC> right-click then change to T-SQL my row level triggers and
CC> apply it to ASE would this be effective?
CC> And would it run as effectively as my triggers in ASA?
You can do anything with statement level triggers that you can do with
row level triggers. You just write them with a different framework in
For example, an update statement changes 5 rows, fires 5 row level
triggers in ASA.
In ASE the trigger fires once, and you must loop through a local
temporary table and address each row.
You can experiment with Sybase Central and have it translate your row
level triggers to TSQL triggers (statement level) and test the results.
I think this might work for you.
Certified ASA Developer Version 8
iAnywhere Solutions - Sybase
Please only post to the newsgroup
Please ALWAYS include version and MORE importantly BUILD number with
EACH post (dbeng9 -v).
EBFs and Maintenance Releases
Developer Community / Whitepapers
CaseXpress - to report bugs
CodeXchange - Free samples
References: <Xns96D85DA06BCA5fishburnsybasecom@127.0.0.1> <firstname.lastname@example.org>
Subject: Re: ASA to ASE Issue
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Original
Date: 21 Sep 2005 09:53:13 -0700
X-Trace: forums-1-dub 1127321593 10.25.98.159 (21 Sep 2005 09:53:13 -0700)
X-Original-Trace: 21 Sep 2005 09:53:13 -0700, rwaywell-xp.sybase.com
Xref: forums-1-dub ianywhere.public.general:4791
Article PK: 17425
Any particular reason for migrating to ASE?
Sybase Adaptive Server Anywhere Developer - Version 8
Sybase Certified Professional
Sybase's iAnywhere Solutions
Please respond ONLY to newsgroup
EBF's and Patches: http://downloads.sybase.com
choose SQL Anywhere Studio >> change 'time frame' to all
To Submit Bug Reports:
SQL Anywhere Studio Supported Platforms and Support Status
Whitepapers, TechDocs, and bug fixes are all available through the iAnywhere
Developer Community at www.ianywhere.com/developer
Subject: Re: ASA to ASE Issue
Organization: RisingRoad Professional Services
References: <43318ff9$1@forums-1-dub> <email@example.com>
X-Newsreader: Forte Agent 2.0/32.640
Content-Type: text/plain; charset=us-ascii
X-Original-Trace: 22 Sep 2005 07:32:50 -0700, 184.108.40.206
X-Original-Trace: 22 Sep 2005 07:32:51 -0700, forums-2-dub.sybase.com
Date: 22 Sep 2005 07:34:02 -0700
X-Trace: forums-1-dub 1127399642 10.22.108.75 (22 Sep 2005 07:34:02 -0700)
X-Original-Trace: 22 Sep 2005 07:34:02 -0700, forums-master.sybase.com
Xref: forums-1-dub ianywhere.public.general:4804
Article PK: 17426
>Guys, I have a question "Why would you choose ASA over ASE?"...
First of all, ASA is now being marketed as an enterprise database
solution, as well as a solution for mid-level and embedded
applications. There is no school system on the *planet* whose
enterprise database requirements could not be handled by an ASA 9
database running on the appropriate equipment. Millions of rows,
thousands of busy users, hundreds of gigabytes, no problem. For some
benchmark and market share reports, see
So why pick ASA over ASE? Let me count the reasons...
- ASA has a more powerful procedural SQL language. That means when
appropriate, it is possible to push complex logic down into the
database in an efficient manner: efficient for the developer to write,
efficient for the engine to execute. ASA has scheduled and triggered
events, row-level triggers, local blob variables, global temporary
tables, persistent local temporary tables, user-defined
connection-level variables, user-defined SQL functions... the list
goes on and on.
- ASA has a more powerful SELECT statement, including local views via
the WITH clause, the LIST aggregate function with ORDER BY, the
recursive union for hierarchical queries, modern OLAP query operators,
ORDER BY clauses on derived tables... this list goes on and on as
- ASA has tools that work: stored procedure and trigger debugger,
capturing of expensive queries, the index consultant, the graphical
plan display. Plus a low-impact remote performance monitoring and
diagnostic tracing tool coming in the next version.
- ASA has simpler administration. You won't get panic calls "The
transaction log is full!" Installation is easier, configuration is
easier, performance tuning is easier (and mostly unnecessary), backup
is easier, recovery is easier, migration from one platform to another
is easier (even to different-endian setups: install the software, copy
the database file, start the server).
- ASA has a lower price tag, not just for licencing but for all those
DBAs you do not need to hire. Everything comes "in the box"... no need
for third-party tool purchases, no need to buy another DBMS to do
OLAP, or another product to do replication.
- ASA has very bright future. The ASA engineers definitely "get it",
they understand what people need from a DBMS, what the default
settings and default behavior should be, why the ANSI standards are
important... they do things the way they should be done. ASA has
always had many important features before the other guy; examples
include declarative referential integrity, row-level locking,
scrollable cursors and the LEFT OUTER JOIN as an alternative to the
unpredictable *= operator.
Sign up for the Beta of the next version:
It will have hot failover, materialized views, snapshot isolation...
once again, the list goes on and on and on...
SQL Anywhere Studio 9 Developer's Guide
Buy the book: http://www.amazon.com/exec/obidos/ASIN/1556225067/risingroad-20
RisingRoad SQL Anywhere and MobiLink Professional Services