error connecting database

[wysiwygger]

Hi,
I have recently upgraded to Accpac 5.4 which is running on a Win2003 Server and SQL 2005.
I have had problems with connecting to the database in 5.3 as well but now it really annoys me.

I can log on to Accpac just fine. Then I open the GL batch list and it opens fine. I close it..wait few seconds then open it again and I get: Error connecting database. I press close and get: Closing the UI due to failure to initialize Accpac DB links.

So I open GL batch list again and it opens fine. I try it a 4th time and I get the same error message.
This could go on forever. Every 2nd time I open the GL batch list I'm getting this error. It's just like with this error something is being reset and I can then start again.

Sometimes this also happens with other Modules such as PO or AR but GL is really bad.

Now, this is only happening on the server. Every client (workstation setup + full installation) appear to be running fine.
I've deleted all data sources as Accpac is connecting straight to the server. Everything got the latest Service Packs installed. ODBCBCP.DLL and SQLSRV32.DLL are identical on Client and Server.
I ran regacc but this was only complaining about w3btrv7.dll which is an old Pervasive dll. (the server used to run on pervasive)
I also ran a4wSignonMgr /regserver to re-register the Signon Manager cause in addition I receive error messages such as: Cannot open the application with stored signon information. I then can't login again cause I get the error connecting database error.

Our Business partner is pretty much clueless and so am I.

Anyone any ideas?

 

[Jay Converse]

Since it's SQL 2005, have you tried the Native driver?

 

[ettienne]

Run RVSpy and DBSpy and see what errors are recorded. I guess the error originates from the database, but I have never seen something like that.

 

[wysiwygger]

Happens with SQL 2005 Native Client as well...
Will have a look with RVSpy and DBSpy....and post the results...

 

[wysiwygger]

ok...i ran DBSpy and RVSpy.
RVSpy: A4W error: 121, DBMS error: 0
DBSpy: same error as above + database driver returned error code 49153

I've only been testing with GL batch list. I get the A4W error: 121 also when GL opens successfully.
Then I left DBSpy on and went into database setup. I've selected my databases (Company and System) hit edit and closed it again.
DBSpy then shows me:
==> 134 <DBS_Table_Exists>
==> A4W error: 134, DBMS error: 0

I've tested the same on my full installation client and I received no errors at all. No 121, 134 or 49153
In database setup - DBSpy shows me:
==> 134 <DBS_Table_Exists>
...but no error.

 

[wysiwygger]

nobody any idea what the problem could be?

 

[Jay Converse]

I've got probably 50 SQL installs, and 20 on SQL 2005, and haven't seen this problem or anything like it.

 

[wysiwygger]

ok...I even removed SQL Server 2005 and re-installed it.
Nothing changed. Still same errors.
No I'm really out of ideas....

 

[ettienne]

Start looking at hardware: bad NIC's, switches, cables and the like can cause intermittent communication errors. In my 20 years of dealing with unexplained errors a high percentage of these were related to hardware.

 

[wysiwygger]

I'm testing in VMWare after I've imported our Server into it.
Since it is happening on the real server and in the virtual machine I doubt it is a hardware issue....

Only thing I can think of now is that it has something to do with Pervasive which used to be installed.
Accpac used to run under Pervasive until 5.1. We then went to SQL 2005.

 

[ettienne]

Did you install all the software (Win2003, SQL2005 and Accpac) on the VM server, or did copy that over?

I would install the OS, SQL2005 and Accpac on a fresh VM, then dump the live Accpac data and load it on the VM server.

I doubt that Pervasive has anything to do with it.

Maybe it is time to contact Accpac tech support.

 

[wysiwygger]

I've converted the server into a VMWare Image which leaves me with a 1:1 copy of my real server in VMWare. No need to install and I can test what I like without breaking anything!

Our business partner contacted Accpac already but I'm not sure they will come up with answers.
It looks like the errors are just to weired...

But if they could tell me what this error means it would be a step forward already I reckon...

==> 134 <DBS_Table_Exists>
==> A4W error: 134, DBMS error: 0

 

[Jay Converse]

Pervasive should not be the issue, those two databases ignore each other. But the weird thing is error 134 has historically only been reported on Pervasive databases.

How about this:

1. Delete ..\SITE\ORGS.ISM
2. Recreate your databases from scratch

 

[ettienne]

I would definitely start with a fresh VM and install all the software, not copy the existing server. That way you eliminate the software as being the source of the problem.