Archiving of database fails at 95%

[JPhillips]

I am trying to archive my database, and when the "copying data" progress bar reaches 95%, archiving fails. In the status box the following statement appears,

'Unable to archive database \\PRIMARY1\D_Lookout_6_1_database. Failed to map database file into shared memory.'

How can I correct this problem?

Any response would be greatly appreciated.

[Ryan.S]

I'm not sure if it's related to the memory size. Try to archive half of the database first, and then archive the left part.

[JPhillips]

Ryan,

I did what you suggested and when archiving the second half the archive failed. I then started archiving from the beginning to say, july. If I did not get a fail, I then archived to August, and so on. I was able to track down where the fail was occurring. When I archived from the beginning to September 8, 2007 at 12:00am. I did not get the fail, but if I archived to September 10, 2007 at 12:00am I did get the fail. I then archived from September 10, 2007 at 12:00am to present day and did not get the fail. So, the fail is being caused by the file(s) for September 8, 2007 at 12:00am through September 10, 2007 at 12:00am.

Is there a way for me to delete just this section of the database so that I can archive the rest?

[Ryan.S]

Are you able to view the trace during this period?

If the database is corrupted, there is an utility for you to repair it. Let me find it.

[JPhillips]

Ryan,

During the period in question I cannot view the trace from approximately 9/9/07 @ 3:30pm thru 9/9/07 @ 5:00p.m.

[erblock]

I had the same error when trying to create a database that used a share other than the default \\\computer\drive_letter$\desired_subdir\Database.

Notice, that I only use hidden shares and I'm unable to use anything other than the default C$, D$, etc.  This is somewhat problematic because those shares can only be used by administrators (on the AD domain, in my case).

I have not checked to see if non-hidden shares can be used besides C, D, etc.

Ed

[erblock]

I did a little more testing, and it seems that you can create a database directly into a hidden share other than c$, d$, etc, but NOT into a subdirectory of a non-administrative hidden share.

This, I can deal with...but It would be nice if you could reproduce ...Ryan?

Ed

[Ryan.S]

You can archive the good part database to a new database, and then use the new one, log data to the new one. I think this can be a workaround.

[JPhillips]

Ryan,

I am trying to archive this database to a different folder on the same computer - I am not dealing with any hidden shares.

With this situation I have 2 parts of the database that are good, the one before 9/8/07-9/9/07 and the one after 9/8/07-9/9/07. Are you saying that I can archive each part and then somehow combine the two. If not, then I have the same question - can I remove the 2 days that contain the corrupted part?

[Ryan.S]

You can archive both parts into the same new database one by one. Then, you should see both data in the database, which looks like a combination.