is it possible to omit GO in Sybase Sql scripts? - sql

I have started doing Sybase programming since some time.the scripts I have encountered are all having GO statements as a batch separator. my question here is is it possible to omit GO in a script and get the script execued?
if yes, will it affect anything at all ?

go is required. It's no different than Oracle and MySQL using ; If you omit the go, the script will not execute.

Related

Convert sql server script syntax to oracle script syntax

I have an application that is supposed to support two types of databases SQL SERVER and ORACLE. So we've been working forever on SQL Server and now we are making this support.
My idea was to create a tool to generate the scripts of creating the database using CMO then convert those scripts to PL/SQL Oracle scripts and run them on Oracle.
My questions are:
Is this syntax conversion possible in code?
I need a guideline to make this kind of syntax conversion.
Do you have a better suggestion to maintain two types of databases (i mean when making a change of one of them, we dont have to make it to the other. we need a tool to make that change.)?
If you write using standard sql it should be mostly portable. Eg use fetch instead of top, SET #a=.. instead of Select #a=.. Use Merge for updates instead of join updates, CURRENT_TIMESTAMP instead of getdate() etc.

Run PLSQL external script with Liquibase

im using Liquibase to manage my database in SQLdeveloper. Now, we have a PLSQL script that runs fine by itself. It also makes the changes in the database. Now, if we want Liquibase to run this PLSQL script it gets the following error: ORA-00922: missing or invalid option.
Is it even possible for Liquibase to run external PLSQL scripts?
There are two potential issues you are running into:
You are using <sqlFile> but not specifying splitStatements="false". By default, Liquibase will split the SQL on semicolons because that is what the JDBC driver needs normally, but in a PL/SQL script you can have a single CREATE PROCEDURE or something similar which contains semicolons but is still one statement. You can also use <createProcedure> instead of sqlFile which does not split statements.
Your script has sqlplus-specific functionality in it. SQLPlus and SQLDeveloper do not simply pass the SQL strings straight through to the database, they have their own functionality to sometimes modify what is actually executed. JDBC and therefore Liquibase does not have all the same functionality and so if you are using it in your scripts they will not work. If this is the case, the best approach is to use a changeSet with <executeCommand> to make a call to sqldeveloper or sqlplus.

Can liquibase syntactically validate the SQL generated using updateSql command?

I found 2 issues per se when I ran the updateSQL commandline in Liquibase
The last statement in Liquibase updateSQL output viz Insert into DBCHANGELOG table does not commit automatically when the sql is run via sqlplus commandline
As a result of this, though the changeset gets executed, the DBCHANGELOG table does not have the insert statement to record it. So when I run the updateSQL once again, the last changeset is once again created in the SQL output which is incorrect.
Liquibase does not validate / check syntax errors in SQL.
As a result of this, even if the changeset SQL fails, the insert to DBChangeLog table for the changeset succeeds which is incorrect. Is there a way that the insert statement following the changeset be stopped / failed if the changeset SQL actually failed ?
Any help is greatly appreciated... we are this close to getting Liquibase implemented... !!
To answer the question in your subject line, no, Liquibase cannot validate the SQL. Liquibase supports many different databases, and each has different SQL syntax.
If you can, stop using the SQL generated by updateSQL to actually do the updates, and use Liquibase itself to do the updates. That way Liquibase can detect errors and behave more properly. I recommend that if DBAs are scared of Liquibase touching the database that teams use the generateSQL as a pre-check to see what Liquibase will do, but let Liquibase do its job.
I also find best practice of Liquibase is not to use a SQL script but to manually write the Liquibase XML file for the change.
I've tried using the ExecuteCommand tag to lunch sqlplus or sqlcmd (as I know my target database) and it has a bug which as for now it is closed?! (but this is open source, so I can't complain :) )
Having said that, I found that working on XML to specify the changes causes many other challenges, for example:
1. Making sure that every change was included in the changelog xml file. I've heard many organizations who forget to add the file to the changelog.
2. Making sure the file for the specific change is always in sync with the file-based version control. Imagine what will happen if it doesn't - which happens to many of my customers...
3. Wasted time spent on merging changelogs between different environments (branches, UAT - critical fixes, sandboxes, etc...)

Incorrect syntax near 'GO' - TADOQuery [duplicate]

This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
How to run a database script file from Delphi?
I have a really long sql script to run with a query, it updates fields, create tables, create procedures, etc. So, there's a lot of the word 'GO' around, otherwise it won't function properly.
On the MSSQL Query the script works perfectly whereas on the ADO Query I get the following:
Incorrect syntax near 'GO'
EDIT: Ok, I think we got it pretty well established that ADO Query will not read the word GO. However, without the word GO my code will not work, procedures must be created in the first line and I have a couple of those thrown around the file. Which is an issue.
The only workaround then would be to create separate queries?
Yes. Remove the GO - it is not valid SQL.
It is syntax specific to Microsoft SQL utilities - see MSDN.
Signals the end of a batch of Transact-SQL statements to the SQL Server utilities.
(emphasis mine)
Go is a batch terminator, it is not SQL, it is understood by SSMS. Just remove the GO when running from ADO
GO is not a SQL command. It is a batch terminator recognized by SSMS

Microsoft T-SQL to Oracle SQL translation

I've worked with T-SQL for years but I've just moved to an organisation that is going to require writing some Oracle stuff, probably just simple CRUD operations at least until I find my feet. I'm not going to be migrating databases from one to the other simply interacting with existing Oracle databases from an Application Development perspective. Is there are tool or utility available to easily translate T-SQL into Oracle SQL, a keyword mapper is the sort of thing I'm looking for.
P.S. I'm too lazy to RTFM, besides it's not going to be a big part of my role so I just want something to get me up to speed a little faster.
The language difference listed so far are trivial compared to the logical differences. Anyone can lookup NVL. What's hard to lookup is
DDL
In SQL server you manipulate your schema, anywhere, anytime, with little or no fuss.
In Oracle, we don't like DDL in stored procedures so you have jump through hoops. You need to use EXECUTE IMMEDIATE to perform a DDL function.
Temp Tables
IN SQL Server when the logic becomes a bit tough, the common thing is to shortcut the sql and have it resolved to a temp table and then the next step is done using that temp table.
MSSS makes it very easy to do this.
In Oracle we don't like that. By forcing an intermediate result you completely prevent the Optimizer from finding a shortcut for you. BUT If you must stop halfway and persist the intermediate results Oracle wants you to make the temp table in advance, not on the fly.
Locks
In MSSS you worry about locking, you have nolock hints to apply to DML, you have lock escalation to reduce the count of locks.
In Oracle we don't worry about these in that way.
Read Commited
Until recently MSSS didn't fully handle Read Committed isolation so you worried about dirty reads.
Oracle has been that way for decades.
etc
MSSS has no concept of Bitmap indexes, IOT, Table Clusters, Single Table hash clusters, non unique indexes enforcing unique constraints....
I get the impression most answers focus on migrating an entire database or just point to some differences between T-SQL and PL/SQL. I recently had the same problem. The Oracle database exists, but I need to convert a whole load of T-SQL scripts to PL/SQL.
I installed Oracle SQL Developer and ran the Translation Scratch Editor (Tools > Migration > Scratch Editor).
Then, just enter your T-SQL, choose the correct translation in the dropdown-list (it should default to 'T-SQL to PL/SQL'), and convert it.
I have to things to mention.
1) When I worked on Oracle 8, you could not do "Select #Result", you had to instead use the dummy table as follows "Select #Result from dual". Not sure if that ridiculousness still exists.
2) In the Oracle world they seem to love cursors and you better read up on them, they use them all the time AFAICS.
Good luck and enjoy,
it is not that different to MS SQL. Thankfully, I do not have to work with it anymore and I am back in the warm comfort of MS tools.
If you replace your ISNULL and NVL nonsense with COALESCE, it'll work in T-SQL and PL/SQL!
It's not trivial to map them back and forth, so I doubt there's a tool that does it automatically. But this link might help you out: http://vyaskn.tripod.com/oracle_sql_server_differences_equivalents.htm
The most important differences for plain T-SQL are:
NVL replaces ISNULL
SYSDATE replaces GETDATE()
CONVERT is not supported
Identity columns must be replaced with sequences <-- not technically T- or PL/ but just SQL
Note. I assume you do not use the deprecated SQL Server *= syntax for joins
#jodonell: The table you link to is a bit outdated, oracle has become somewhat more standards compliant after 9i supporting things like CASE and ANSI outer joins
I have done a few SQL server to oracle migrations. There is no way to migrate without rewriting the backend code. Too many differences between the 2 databases and more importantly differences between the 2 mind sets of the programmers. Many managers think that the 2 are interchangeable, I have had managers ask me to copy the stored procedures from SQL server and compile them in oracle, not a clue! Toad is by far the best tool on the market for supporting an oracle application. SQL developer is ok but was disappointing compared to toad. I hope that oracle will catch their product up to toad one day but it is not there yet. Have a good day :) chances are if you are migrating to oracle it is for a reason and in order to meet that requirement you will need to rewrite the back end code or you will have many issues.
In Oracle SQL Developer, there is a tool called Translation Scratch Editor. You can find it from Tools > Migration.
The Oracle SQL Developer is a free download from Oracle and it is an easy install.
If you're doing a one-off conversion, rather than trying to support two versions, you must look at Oracle Migration Workbench. This tool works with Oracle's SQLDeveloper (which you really should have if you are working with Oracle). This does a conversion of the schema, data, and some of the T-SQL to PL/SQL. Knowing both well, I found it did about an 80% job. Good enough to make it worth while to convert the bulk of procedures, and hand convert the remainder "tougher" unknown parts.
Not cheap ($995) but this tool works great: http://www.swissql.com/products/sql-translator/sql-converter.html
A few people have mentioned here converting back and forward. I do not know of a tool to convert from MSSQL to Oracle, but I used the free MS tool to convert a Oracle db to MSSQL and it worked for me and converted a large db with no problems I can call. It is similar to the Access to MSSQL tool that MS also provide for free. Enjoy
jOOQ has a publicly available, free translator, which can be accessed from the website here: https://www.jooq.org/translate
It supports DML, DDL, and a few procedural syntax elements. If you want to run the translation locally via command line, a license can be purchased and the command line works as follows:
$ java -cp jooq-3.11.9.jar org.jooq.ParserCLI -t ORACLE -s "SELECT substring('abcde', 2, 3)"
select substr('abcde', 2, 3) from dual;
See: https://www.jooq.org/doc/latest/manual/sql-building/sql-parser/sql-parser-cli
(Disclaimer, I work for the vendor)