Prolog: I admit, that's obviously no question to solve a real problem but to satisfy my curiosity. Feel free to take it as some kind of gossip:) Often enough, someone in the newsgroups or on this site yells - or sighs - or shakes his head: "Ah, why on earth wasn't I aware of this?!" just after getting a hint to use a particular feature (say, derived tables, the MERGE statement or whatever). Or in a similar way, one has read about this new feature (possibly in a What's new section of the docs) but it takes months/years until one comes to use it the first time - and then comes the conclusion it could have made several tasks much easier in the past. Or from another point of view, say, when you're working with different SA versions, what are the typical features you are about to use and then realize (for the nth time) that they aren't supported in the older version? If this sounds familiar to you, I think you could share these moments of enlightenment and help others to get to know those facilities, too, in case we haven't yet noticed their usage. Epilog: This may be connected to Breck's current "Pushing" series on his blog where he tells of such features... |
One of my favourites (well, one I have been aware of since ASA 9 was released but one I'm regularly missing while working with ASA 8):
From the ASA 9 What's new docs:
It's very convenient to be able to join procedure result sets with other tables/views or to filter out rows/columns or use a different sort order. In older versions, you would have to use some logic to insert the procedure's result set into a temporary table or the like and then use that table for further processing - cf. this question. |
Yet another one:
Between these two I can quickly generate the SQL to take structure and data from one setup to another. |
|
execute immediate The below example isn't something I run very often. I originally created it so we could "do something" when users complained their databases suddenly slowed down. Instead I keep it around as a template to use with execute immediate.
2
We often use this type of setup. We setup some SQL within a text variable and then "fill in the blanks" with dynamic information from another variable. @Breck: One of my favourites, too, w.r.t. xkcd:) Yes! Use heavily with rules based student billing.
(11 Feb '21, 09:40)
rsnyder
|
Another secret favourite: MESSAGE ... DEBUG ONLY and the debug_messages option (both introduced in ASA 9.0.1). Used for a bunch of complicated stored procedures with a lot of diagnostic messages. In older versions, I usually insert such messages during development and remove them (or comment them out) once the code works as expected - but that means one has to alter the code again. With DEBUG ONLY, I usually leave them inside and can activate them on demand. (Sometimes, one wishes one could differ in finer degrees, i.e.not just DEBUG Yes/no, but that's a different issue). That being said, my heavy usage of MESSAGE statements testifies that I had not yet explored the full debugging facilities within Sybase Central until lately... a further "I wish I had knew you before" moment:) 1
One of my favorites too... it is often much faster to find a problem using MESSAGE than with [cough] "more powerful" techniques. It is a challenge, however, when you have many services and events because each one must turn DEBUG_MESSAGES on or off. @Breck: "each one must..." - are you sure? I've always thought that option (as a database option) just must be toggled on/off once? |