|
We have upgraded our database from sqlanywhere 11 to 16. Unfortunately after the update all views, procedures, functions in sybase central have quoted column names. f.e. SELECT "customer_id", "customer_name", "customer_nr" as "cNr" from "customer" Is there an option to disable these quotes? I tried with "SET quoted_identifier Off;" but this didn't work. |
|
See this FAQ which basically tells this is by design with SQL Anywhere 16 and above and also explains that you can use the PRESERVE_SOURCE_FORMAT option to have the objects stored formatted exactly as you have used within the according CREATE/ALTER statements. If you have not yet set that option, you will need to re-create/alter those objects with the desired formatting. 1
While PRESERVE_SOURCE_FORMAT is helpful, it's always worth suggesting that procedure, view, trigger, and event code should be treated as original source code, and should be edited and maintained as text files outside of the database.
(02 Sep '20, 08:56)
Breck Carter
Thanks Volker, it works perfectly. I've been looking for this solution for a long time. @Breck what are the advantages saving the source code as files? do you use a version control system? How do you sync between files and the DB? And what are the disadvantages of preserving source format, i only read about "disk space" cause the definitions are stored twice.
(02 Sep '20, 09:51)
tbr-baehren
Replies hidden
3
The "sync" between the source code files and the DB is done by a "compile" process similar to one used to create *.exe files from *.c and other source files. In the case of *.SQL files dbisql.exe is the "compiler", and another *.SQL containing READ statements is the "make" file... if you have a lot of procedures and want to automate compilation. Source code is any code directly created and changed by developers. Lots of people use version control systems for all of their source code... BUT... Even a manual method is better than storing one single copy inside the database. It gives you the freedom of creating separate test versions of the procedures, compiling them into test databases, before publishing them to production. If the production database is the only repository for procedure code then, presumably, testing is done in production. Disk space is not ever a problem, in any system, when it comes to preserving source code... a single USB stick could store more source code than an army of developers could create in a lifetime :)
(02 Sep '20, 10:46)
Breck Carter
2
Yes, we certainly do use version control for all database scripts, and even for ad-hoc queries, I usually get soon to the point that I want to conserve the "development efforts" itself, just to be able to document how something has evolved or why certain queries are done that way and not another... And to preserve them for later times. - It also automatically makes the code feel "worthier" :)
(02 Sep '20, 11:26)
Volker Barth
|
