|
Is it possible to have comments in the parameter configuration for a db service (Sybase Central). This is useful for a development environment where you'll repeatedly change database paths. update: As this question now have been answered I am retagging this as an product-suggestion. |
|
As Arthoor says you can use the # style comment if you use a configuration file but unfortunately NOT on the command line or in the Sybase Central service properties configuration tab (checked v12.0.1 & v10.0.1) . It would be useful - you might want to re-tag your question as "product-suggestion" :) For comments on a command line, that would be a product suggestion for the OS (Windows, Linux, etc). For Windows, the comment statement is REM.
(31 Jul '12, 12:07)
Breck Carter
Replies hidden
I mean within the SQLAnywhere parameters. After all, although when you set up a service you can have each parameter displayed on its own line -n MyServer what gets executed is what gets executed as the service command line is: "c:\program files\sql anywhere 12\bin32\dbsrv12.exe" -n MyServer -x tcpip d:\mydatabase.db -n MyDatabase What would be good would be if you could set up your service parameters: -n MyServer so the command line would be "c:\program files\sql anywhere 12\bin32dbsrv12.exe" -n MyServer -x tcpip #desperate attempt -c 500P -gb GoMuchFaster #end desperate attempt d:mydatabase.db -n MyDatabase where #desperate attempt etc would be ignored as it is in the command file. I presume that what happens at the moment is that the mechanism that parses the command file discards # comments as it goes along.
(31 Jul '12, 12:28)
Justin Willey
I understand, but it's still an OS issue, not a SQL Anywhere issue, at least as far as operating system command lines go. FWIW you can break DOS/Windows command lines onto multiple lines using the ^ character; for some examples see http://sqlanywhere.blogspot.ca/2011/04/recovering-across-multiple-backup.html Caveat Emptor: Don't accidentally type any spaces after a tilde ^, that way lies insanity :) What you can't do, is intersperse comments... they have to appear in a separate section in REM commands, which is what I do in various template command scripts; for example: REM dbinit... REM -e simple encryption REM -et enable table encryption REM -s use checksums when writing pages REM dbspawn... REM -f do not check for a running server. REM -q quiet mode — do not print messages. REM dbsrv10... REM -c ... initial RAM cache size REM -o ... where to put server console log text file REM -oe ... where to put fatal error log text file REM -os 10M when to rename/restart console log text file REM -x none only allow "shared memory" client connections REM -z diagnose communication links REM -zl RememberLastStatement for LastStatement REM -zp RememberLastPlan for LastPlanText REM -zt RequestTiming for performance statistics REM ddd12.db first database to start REM dbisql... REM -c ... database connection string "%SQLANY12%\bin32\dbinit.exe"^ -et^ -s^ ddd12.db "%SQLANY12%\bin32\dbspawn.exe"^ -f "%SQLANY12%\bin32\dbsrv12.exe"^ -o dbsrv12_log_ddd12.txt^ -oe dbsrv12_log_fatal_ddd12.txt^ -os 10M^ -x tcpip^ -z^ -zl^ -zp^ -zt^ ddd12.db "%SQLANY12%\bin32\dbisql.com"^ -c "ENG=ddd12;DBN=ddd12;UID=dba;PWD=sql;CON=ddd12-1" "%SQLANY12%\bin32\dbisql.com"^ -c "ENG=ddd12;DBN=ddd12;UID=dba;PWD=sql;CON=ddd12-2" PAUSE
(31 Jul '12, 17:09)
Breck Carter
|
...and in production, to inform future maintenance folks why the "-weird" option was picked. In particular, options are sometimes picked for very strong reasons (like it won't work without them), and others are picked for feeble reasons (e.g., desperate attempts to improve performance), and it's important to know the difference, especially when the rules change in future versions of the product (e.g., -gn has been revolutionized).
For example, if you hire an
overpricedoutside consultant to advise you on performance, comments on options may help guide them away from making clueless suggestions.