0

I'm creating this process on uDeploy that uses iSQL to execute sql files. My problem is that I have to set the server and db name in the process.

In the SQL file - we may need to use other db's so it'd have to include USE DBNAME GO in the file.

However, it hasn't been reaching/executing the update statement after the USE statement.

Is there anything in relation to sybase, isql, that doesn't allow this? Can you only do one statement from isql?

typical linux cmd being run is

sybase.sh; isql -U username -P **** -S servername:port -D dbname -X -i sqlfile.sql

SQL file example:

USE dbname
go
update table set field = 'date' where field1 ='blahblah' and field2 ='blah'
go

edit:

This might be because the DBNAME is being set in the command. Can anyone confirm?

k murray
  • 1
  • 1
  • 2
  • 1
    A table has _columns_, not fields. – jarlh Dec 01 '17 at 13:40
  • alright - wrong word, but that doesn't add to the solution. Anyway, its because of hte dbname being set in the command probs, haven't seen anyone trying to change db within this so can't know for sure. – k murray Dec 01 '17 at 13:49
  • would help if you updated your example with some sample database names; as is, `dbname` == `dbname`, so both examples should run your query in a database named `dbname` ... assuming your login has access to a database named `dbname`; I'm assuming you're got differently named databases ... in which case I've explained one probable issue (see my answer - below) – markp-fuso Dec 01 '17 at 17:17

1 Answers1

1

Some background:

From the command line:

isql -U ... -P ... -D >dbname< -i >script<
  • will run >script< in the database named >dbname< (assuming your login has access to the >dbname< database; otherwise the script will be run in your login's default database)

In a script:

use >dbname<
go
select ...
go
  • assuming your login has access to database >dbname< ...
  • will place the session in the database name >dbname< and ...
  • then run your query
  • if you don't have access to the >dbname< database then you should get an error message and the follow-on query(s) will be run in your default database

Your (probable) issue:

  • while the isql / -D >dbname< will set the destination database ...
  • the use >dbname< in the script will take precedence and determine which database you're ultimately placed in prior to running the follow-on query(s)

An example ...

$ myquery.sql
use tempdb
go
select count(*) from sysobjects
go

$ isql -S ... -U ... -P ... -i myquery.sql
  • since no -D argument is provided on the isql command line, the script will place you in the tempdb database prior to running the select

Now if we add a -D flag ...

$ isql -S ... -U ... -P ... -D master -i myquery.sql
  • while the isql command line option -D master will initially place your session in the master database ...
  • the script will override this by then placing you in the tempdb database
  • net result is the select will be run in the tempdb database
markp-fuso
  • 28,790
  • 4
  • 16
  • 36