Trouble Restoring Database

[JBulcher]

We recently installed SQL Express on one of our computers, and we are trying to move the old AVAST database over to it. The installation of AMS goes fine, but when we try to restore a backup file, we are receiving two error messages:

Cannot execute internal SQL command, error 0x80040E14
RESTORE DATABASE is terminating abnormally.
Cannot open backup device '(path & filename of .bak file)'
Operating system error 5(Access is denied.).

and

Error while restoring the database
Error: 42000

[bslorence]

I'm also seeing this problem. We tried to get some more information with DebugView, but it wasn't very helpful:

00000000        0.00000000      [3236] Posting quit message... 
00000001        0.00007188      [3236] Quiting message loop... 
00000002        0.00175898      [3236] Setting quit event...   
00000003        0.00179341      [3236] Destroying server object...     
00000004        0.84706491      [3236] Purging an old connection...     
00000005        0.84765452      [3236] Purging an old connection...     
00000006        0.84775567      [3236] sqlPurgeConnectionPool exit: total num = 0       
00000007        0.84873509      [3236] Freeing low level scheduler...   
00000008        0.84915459      [3236] Closing quit event...   
00000009        24.00079536     [3708] Calling sqlInit()...     
00000010        24.50180626     [3708] quiting sqlInit()...     
00000011        24.50184250     [3708] Loading storage...       
00000012        24.50274277     [3708] calling UploadSetupPackagesToDB()...     
00000013        24.70663452     [3708] calling sqlGetConnection()...   
00000014        24.77033424     [3708] Doing the winsock stuff 
00000015        24.77222443     [3708] Initializing the listener       
00000016        24.82615852     [3708] serInitLibrary done...   
00000017        24.82833099     [3708] Entering modal loop...

The first 8 lines show up in DebugView -- then the first error message from JBulcher's post appears. We hit OK, then the second error appears, and no change in DebugView. Finally, after we hit OK on the second error window, lines 9-17 show up in DebugView.

We could manually re-build our configuration on in SQL Server Express, but it would be really nice not to have to do that. 

And, if no one has any ideas about why we can't restore from backup: Has anyone ever manually exported Avast stuff from one database and manually imported it into another? If so, are there any tricky spots we should be aware of before we try it?

Thanks,

Ben

[Vlk]

Is the path to the backup file (in the error message) correct?

bslorence, you're restoring a SQL2000 backup to SQL2005? I'm not exactly sure this can be done...

[bslorence]

Yes, the path is correct.

bslorence, you're restoring a SQL2000 backup to SQL2005? I'm not exactly sure this can be done...

I guess that's my question, then: can it be done? And if there's a database incompatibility, why does the error message say "operating system error 5(Access is denied)"?

More details: the backup is from a computer running AMS v4.6; and I'm trying to restore with AMS v4.7. Could this be the source of the problem?

Thanks,

Ben

[JBulcher]

After waiting for a reply as to wether or not the differences in the database versions was causing the problem, we went ahead and switched over the old database to the newdatabase server without importing the old database. Initially everything went fine, but after 1/2 hour - 3/4 hour all of the Win XP computers on our network stopped responding when opening /saving files. The programs that were running at the time continued to run without incident, even though the GUI was unresponsive on that machine (e.g. ADNM was accessible, as well as network services we have running on Win XP machines).

Looking into the virus logs of the effected computers we discovered this error affecting the computers: "Error in aswChestS: chestStart Error 1740."

What causes this problem, and is it something to be worried about?

[vojtech]

The error message means that the virus chest on this computer will not work. It could happen if the avast service terminated incorrectly. It was probably caused by overwriting avast settings with values from the new database. The chest should be OK after next restart. And the problem with accessing files solved itself or continues ?

[JBulcher]

So far we haven't had any problems since rebooting. Could the issue have been caused by a scan of files being held up by an error in Avast, perhaps relating to the virus chest?

[vojtech]

I think that the problem is not much related to the chest, it's malfunction was just a consequence of the problem.

[bslorence]

It could happen if the avast service terminated incorrectly. It was probably caused by overwriting avast settings with values from the new database.

Would this overwriting be a normal and expected consequence of switching from AMS v4.6 with a fully-populated database to AMS v4.7 with an empty database? 

Thanks,

Ben

[vojtech]

What do you mean by 'switching to AMS v4.7 with an empty database' ? Normally, the database is preserved when you upgrade the AMS.

[bslorence]

Here's the whole scenario, from the beginning:

We had AMS v4.6 running on computer A, using an MSDE database, also installed on computer A.

We then installed SQL Server 2005 Express on computer B, and AMS v4.7 on the same computer, and pointed the new AMS at the new database. Then, we tried to migrate our old data from the MSDE on computer A to SQL Server on computer B, by running a backup job on the AMS on computer A, and then trying to restore the backup on the AMS on computer B.

As detailed earlier in this thread, our efforts to migrate the database failed. So the new database on computer B was more or less empty. I think that the tables were created when we installed the new AMS, but that's it.

So then we (unwisely?) took a chance and just stopped the AMS on computer A, and let the clients figure it out. They all re-pointed themselves to the AMS on computer B. But that AMS was using an "empty" database.

At this point all of the client machines "froze up", but not really. That is to say, anything that was already running on them (interactive processes or services) kept running just fine, but as soon as we tried to do anything that involved opening a file, we would lose desktop interactivity. We could still use non-interactive remote management tools, at least to some extent. And we found that if we remotely killed the process Avagent.exe, we could regain interactive control of the computer.

Unfortunately we found that out too late, and had already restarted most of the computers in the network, which also solved the problem.

So, I guess the question is: what exactly happened, and why?

Thanks,

Ben