Not always. As I mentioned, sqsh is a very good replacement.
Oracle is that way (sqlplus).
At least, you don't have to type:
>select * from anytable [enter]
>go [enter]
You have command history, command editing (not readline, though) and you can redirect its output to a file.
MS SQL Server is that way (isql/osql).
Not a surprise, given that Sql Server and Sybase were once the same program. Anyway, SQLSRV has Query Manager. I know it is a GUI tool, but since you are supposed to do things graphically in Windoze, it is the default query tool.
You ate a little too much red herring for breakfast.
:-) Not really. As I stated in the subject, this is my experience on migrating to Sybase, and I wanted to share it with/. readers
ASE 12.5 runs just fine on plenty of Linux distros. We run it in production on Red Hat 7.2. It will NOT give "Infected with 11" errors simply because you're on a different (non-supported) distro; it gives you those errors if libraries are missing/not the right version.
I tried to install it on Slackware, releases 9.1 and 10. First, it complained about Slack not using PAM, so I installed it. Then, after everything seemed to be fine, I started the server and it showed the error messages on its log.
Also, I tried intalling ASE 12.5.1 on Suse 9.o, and it didnt't even finish the installation proccess, breaking on the db creation step. This was only solved using ASE 12.5.2.
What I mean is that using a distro that is not on Sybase's supported list is risky.
Are you on drugs? Not only are most of MySQL's datatypes against the SQL standard, but ASE supports:
int (-2,147,483,648 and 2,147,483,647), inclusive.
smallint (-32,768 and 32,767), inclusive.
tinyint (0 and 255), inclusive
Whoops, sorry about that, you are correct, what I said only apllies to mediumint. But there's still a problem with the unsigned option, which changes the value range to the positive side, eg unsig smallint=0 to 65536. In this case, if you have records that have values above 32767, there's no way but to upgrade the type to int.
I also had problems with:
Timestamp - not the same type in MySQL and Sybase, although using the same name;
Date, Time - Sybase only has datetime, so when setting just time it assumes a fixed date, the same happening with date.
Autoincrement - Sybase calls it identity, and it doesn't accept it as parameter of an integer type, enforcing numeric(38).
Blame MySQL and PostgreSQL for not correctly implementing the ANSI SQL STANDARD SPECIFICATION for escaping characters. This is the same as if you wanted to migrate to Oracle or Microsoft SQL Server, or any other product that correctly interprets this ANS SQL standard feature.
I agree, it is very difficult migrating db's that used all the 'extra' features of MySQL/Postgres to a more standard DBMS. And that's why I said it is not worth it migrating from MySQL/Postgres to Sybase.
Since I've used Sybase ASE 12.5 recently, I'd like to make Some considerations:
-It is very sensitive about the OS configuration, only runs well on supported platforms (RH Enterprise, Suse, etc). If it finds anything not conforming its requirements, displays the annoying "Proccess is infected with 11" (meaning Segmentation faults). -CLI client totally crippled: the user has to type go after each command, no line-editing, no history, poor output formatting. Fortunately, sqsh, mentioned on parent, is a nice replacement. -ODBC driver for Unix/Linux not available for free. -Native C/C++ API, ctlibrary, implements a finite state machine, enforcing the programmer to ask twice if the result set is done. -Conversion to Transact-SQL data types from MySQL or Postgres is very tricky, because it doesn't have sub-integer types (smallint, mediumint, etc). Also, it uses different escape characters: eg. '' (two apostrophes) to represent one apostrophe inside a delimited string.
From what I saw, it's not worth it migrating from MySQL or Postgres. If the migration is from MS SQL, though, it is a very interesting move, since the compatibility among the two is is still good.
Slashdot Mirror
Guess what? that's the way the CLIs are.
Not always. As I mentioned, sqsh is a very good replacement.
Oracle is that way (sqlplus).
At least, you don't have to type:
>select * from anytable [enter]
>go [enter]
You have command history, command editing (not readline, though) and you can redirect its output to a file.
MS SQL Server is that way (isql/osql).
Not a surprise, given that Sql Server and Sybase were once the same program. Anyway, SQLSRV has Query Manager. I know it is a GUI tool, but since you are supposed to do things graphically in Windoze, it is the default query tool.
You ate a little too much red herring for breakfast.
:-) Not really. As I stated in the subject, this is my experience on migrating to Sybase, and I wanted to share it with /. readers
ASE 12.5 runs just fine on plenty of Linux distros. We run it in production on Red Hat 7.2. It will NOT give "Infected with 11" errors simply because you're on a different (non-supported) distro; it gives you those errors if libraries are missing/not the right version.
I tried to install it on Slackware, releases 9.1 and 10. First, it complained about Slack not using PAM, so I installed it. Then, after everything seemed to be fine, I started the server and it showed the error messages on its log.
Also, I tried intalling ASE 12.5.1 on Suse 9.o, and it didnt't even finish the installation proccess, breaking on the db creation step. This was only solved using ASE 12.5.2.
What I mean is that using a distro that is not on Sybase's supported list is risky.
Are you on drugs? Not only are most of MySQL's datatypes against the SQL standard, but ASE supports: int (-2,147,483,648 and 2,147,483,647), inclusive. smallint (-32,768 and 32,767), inclusive. tinyint (0 and 255), inclusive
Whoops, sorry about that, you are correct, what I said only apllies to mediumint. But there's still a problem with the unsigned option, which changes the value range to the positive side, eg unsig smallint=0 to 65536. In this case, if you have records that have values above 32767, there's no way but to upgrade the type to int.
I also had problems with:
Timestamp - not the same type in MySQL and Sybase, although using the same name;
Date, Time - Sybase only has datetime, so when setting just time it assumes a fixed date, the same happening with date.
Autoincrement - Sybase calls it identity, and it doesn't accept it as parameter of an integer type, enforcing numeric(38).
Blame MySQL and PostgreSQL for not correctly implementing the ANSI SQL STANDARD SPECIFICATION for escaping characters. This is the same as if you wanted to migrate to Oracle or Microsoft SQL Server, or any other product that correctly interprets this ANS SQL standard feature.
I agree, it is very difficult migrating db's that used all the 'extra' features of MySQL/Postgres to a more standard DBMS. And that's why I said it is not worth it migrating from MySQL/Postgres to Sybase.
Thank you too!
Since I've used Sybase ASE 12.5 recently, I'd like to make Some considerations:
-It is very sensitive about the OS configuration, only runs well on supported platforms (RH Enterprise, Suse, etc). If it finds anything not conforming its requirements, displays the annoying "Proccess is infected with 11" (meaning Segmentation faults).
-CLI client totally crippled: the user has to type go after each command, no line-editing, no history, poor output formatting. Fortunately, sqsh, mentioned on parent, is a nice replacement.
-ODBC driver for Unix/Linux not available for free.
-Native C/C++ API, ctlibrary, implements a finite state machine, enforcing the programmer to ask twice if the result set is done.
-Conversion to Transact-SQL data types from MySQL or Postgres is very tricky, because it doesn't have sub-integer types (smallint, mediumint, etc). Also, it uses different escape characters: eg. '' (two apostrophes) to represent one apostrophe inside a delimited string.
From what I saw, it's not worth it migrating from MySQL or Postgres. If the migration is from MS SQL, though, it is a very interesting move, since the compatibility among the two is is still good.