Suppress header in output of sybase query in Linux

First: This isn't easy to implement and it's going to break very easily (by which I mean performance is going to be horrible, and it's a nice little route for SQL injection attacks if you're not very very careful). I strongly advise you to re-think what you're doing because there has to be a better way.

Second: The question as it stands doesn't actually make sense - what condition are you checking on the columns? NOT NULL? Also, do you want to AND or OR the conditions together?

To actually answer the question, though, to do this you'll need to write some dynamic SQL:

• Link sysobjects to syscolumns, filter by the table name and the fields you're interested in.
• Build a executable SQL statement using a cursor, then execute it.

Example below is, for each column in the Users table that starts with either 'A' or 'B', return all rows in the Users table that have a non-null value in any of those columns.

Note: I don't have a Sybase install handy to test this. Chances of it actually working are very low, but it should hopefully be enough to make you realise what a bad idea this is.

DECLARE @colname nvarchar(255),
        @sql nvarchar(4000)

SET @sql = 'SELECT * FROM Users WHERE '

DECLARE colcur CURSOR FOR
    SELECT sc.name 
    FROM syscolumns sc 
            INNER JOIN 
         sysobjects so ON so.id = sc.id
    WHERE so.name = 'Users'
        AND so.type = 'U'
        AND (sc.name LIKE 'A%' OR sc.name LIKE 'B%')
    ORDER BY sc.name
OPEN colcur

WHILE 1=1
BEGIN
    FETCH colcur INTO @colname 
    SET @sql = @sql + @colname + ' IS NOT NULL OR '
END

DEALLOCATE colcur

SET @sql = LEFT(@sql, LEN(@sql) - 3) -- need to trim off the trailing 'OR'

EXEC @sql

Sybase ASE does not support a direct upgrade from version 11.5 to version 15, so you will have to export your database from the ASE 11.5, and import it to ASE 15.

From the $SYBASE/$SYBASE_ASE/scripts/ directory in your ASE 15 installation, run the installupgrade file into your ASE 11.5 installation, to install some utility stored procedures to assist with the migration.

isql -Usa -Ppassword -SOLD_SERVER_NAME -iinstallupgrade

Now login to each database, and run the sp_checkreswords command to make sure none of your DDL is using words reserved for the system. If reserved words are found, you will need to alter the code, and remove/change the reserved words.

Use the ddlgen utility to export your full database structure (Tables, indexes, stored procedures, defaults, user defined datatypes, etc.)

At this time, you may want to review the code generated by ddlgen, to make sure it makes sense in your new environment. You may want to make changes to device locations, device names and device sizes. For example, ASE versions prior to 12.5 had a device size max of 2 Gb, so if your database was 10 Gb, you were forced to have 5 devices. ASE 15 will allow device sizes of up to 1 Tb (on a server with a 2k page size), so you would only need one device to store the entire database.

You may also want to seperate the index and trigger creation scripts from the rest of the DDL, to allow you to run those independantly. This comes in handy when you import data into the new server.

Once you are satisfied with the scripts, you can run them against the new server, and it will create all of your database structure on the new server.

At this point it's a matter of transitioning the database, using the bcp utility, you will need to export your data on a Table by Table basis. Depending on the size of your databases, and the number of tables in each database, this can take a while. I would recommend trying the -n (native) version of bcp instead of the -c (character) if it's possible.

To import the data into your new database, you will also want to use the bcp utility, but you will likely want to make sure that your databases do not have triggers or indexes as this will enable the 'unlogged' version of bcp to run, allowing it to run faster and not fill the transaction log as it runs. If you can not run the unlogged bcp then you will want to make sure you have the appropriate database options ('truncate log on checkpoint', 'abort tran on log full') and set the batch size for your import to a reasonable value.

At this point, you can create in indexes and triggers (if they haven't been created up to this point), and start testing the server.

I would also recommend reviewing Sybase's Migration Guide, as it will likely go more in depth, and cover things I may have forgotten/skipped over. A lot of the details will depend on the migration environement, so planning and preparation are key.