|
Hello I'm trying to upgrade an 11 database to 16. I have tried via command prompt using both the dbupgrad command and also dbunload. At this point I am getting an error: SQL error (-30000) – RAISERROR Executed: Invalid Sybase Driver, must use ‘SQL Anywhere 11’ driver I have also tried this via the GUI and get the same error with the following additional information: SQLCODE=-30000 SQLSTATE=HY000 Any help would be appreciated. Thanks Russ |
|
I have located the procedure that was causing the issue. There was a custom procedure that replaces the standard login procedure "sp_login_environment" in the sybase db options. Thanks for your help. |
That message looks like it is coming from a user-written RAISERROR statement inside custom SQL code, somewhere in a stored procedure, trigger, or other block of code inside the database. -30000 is not an "official" SQLCODE value, it is a custom user-created value.
Do you get this error message when trying to run dbupgrad or dbunload, or do you get it afterwards when you try to connect to the database?
WAG: You may have a "login procedure" with some code that needs to be modified or removed.
I get the error message when trying to run dbupgrad or dbunload. I can't connect either, with the same issue, stating I must use ‘SQL Anywhere 11’ driver. I can start the database using the dbsrv command
But can you also connect to the database on v11? And if so, do you have a login procedure in place, as Breck has asked?
It appears that this is indeed a custom error thrown. One of the procedures restricts connections to anything that is not version 11. I've been told I have to unload the database and search for the error code to discover which procedure it is. Any advice on this would be appreciated.
Then I guess you will have to use v11's dbunload to generate an according reload.sql file (e.g. "%SQLANY11%\bin32\dbunload -n -c <yourconnectionstring> reload.sql") and then search through that to find the according procedure - or simply use Sybase Central to inspect the procedures's code...
As this procedure seems to influence each connection, I would follow Breck's hint that there is a particular "login procedure" in place - what does the following reveal when used within DBISQL?
If that does not return NULL, it should tell you the name of the according procedure which might have to be modified (or any procedure called by that one).