A windows service I developed – which uses Sybase ADO.NET drivers to connect to a Sybase database – suddenly stopped working yesterday. The log files showed a sybase exception described as Internal error 30016. We had a contingency server on which a copy of the main database is loaded daily, so I tried connecting to this one and the error did not show up. This led me to believe that something had been changed, and I asked the local Sybase DBA if something had changed. He was clueless.
Restarting the service did not help, so I started googling “sybase error 30016”. I found the solution on stackoverflow: it had something to do with the default network packet size setting on the server. I looked up the connection string setting for “packet size” from Sybase Infocenter and then i added it to my application’s app.config, setting it to 2096 like the below (scrubbed, of course)
<add name="aequinox" providerName="Sybase.Data.AseClient" connectionString="Data Source=xx.xxx.xxx.xxx,xxxx;Initial Catalog=staging;User Id=xxxxx;Password=xxxxx;PacketSize=2096;CharSet='iso_1'" />
I restarted the service again and the problem went away. I still don’t know why it worked, and I don’t really want to know. I hate working with Sybase.
The error came back the very next day! After going over all the changes made to each component of the system, we discovered a ‘tweak’ made by one of the database developers on the main stored procedure used by the application. In this ‘tweak’, a table was being dropped and recreated using a “select into” statement at each call of the stored procedure, like so:
insert into csa_cc_tc
select charge_code ,effective_dt,status,empl_id,create_dt,1 ,description
select tran_code ,effective_dt,status,empl_id,create_dt,debit_credit,description
Strange, I know. Blame the Sybase database developer, the code wasn’t commented and I have no idea why he’s doing that. I read from this blog that
another condition that raises this error is if your query outputs a column that is SMALLDATETIME NOT NULL.
… Sybase tech support … advised us to upgrade the .NET PC Client to the latest EBF (ebf13008). This magically solved all these internal error problems.
Incidentally, this drop-table-create-table routine does select a non-null smalldatetime field. Getting the latest EBF was not an option, and I couldn’t alter the table DDL. Instead, I moved the statement block into another stored procedure which is not called by my application, but is guaranteed to execute before my application starts up anyway.
Now the problem is gone – for real this time.