FW: VSS Import Errors

Thanks Eric,

I'd been through the 12 step program to VSS import happiness, but failed
to do a couple of basic checks which would have isolated the problem (my
own stoopid fault). That said, I know what the drama is but can't seem
to fix it.

The machine I'm, importing has the whole box and dice installed, but
fails on every trasnaction. If I point the import tool to an alternative
Vault server (the initial one I set up using the demo), I can run the
import. Running it against the local Vault server (which is what I
really want to do) consistently fails.

I'm getting a FailDBInsert error. This occurs both using the import
tool, and using the Client tool to simply create a project folder in the
root. It looks like the CommitTrans call is failing, given that it's
unable to open/find/instantiate the XML object. It's throwing an error
against MSXML2.DLL, but in theory, I've got MSXML4 installed in replace
mode, so it should map the call through to there.

I'm trying to dig up an XML2 install at the moment and see if that fixes
the problem, but so far haven't located a setup package (haven't looked
that hard yet).

So, the current status is that I've got to sort out this drama, and then
hopefully I'll be away. Having had some further success with the
secondary Vault server import, I should be able to get my DB imported in
about 7-8 days, which is acceptable.

Matt

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Eric Sink
Sent: Thursday, 18 December 2003 01:50
To: [email protected]
Subject: RE: [vault-list] VSS Import Errors



I'm sorry you're having so much trouble with
the import tool.

Our first step in helping resolve any problem
with the import tool is to make sure you've
read the following tips.   

If you've followed the instructions below and
are still having problems, we are of course 
available to work with you and get it figured
out.  This list of tips is just a starting point.

We're trying to make sure people get this 
document and read it *before* they lose 9 hours 
of their life, but we're not quite there yet.  :-(

----

Importing a SourceSafe database into a Vault
repository is a big operation.  In some cases, the
full import can take several days, so it's worth
making sure that everything is configured properly
at the beginning.  A little careful planning can
avoid a lot of frustration.  

The following tips will help your import go as
quickly and as smoothly as possible.

1.  We recommend that you use two different
    machines.  One machine should be running the
    Vault server, including SQL Server.  The other
    machine should be running the VSS Import Tool,
    and your VSS database should be on that machine
    as well.  The import will go much faster if both
    these machines have plenty of RAM and fast hard
    disks.  The network connection between these two
    machines should be fast, at least 10-baseT and
    preferable 100-baseT.  Ideally, neither machine
    should be occupied with any other tasks during
    the import.

2.  During the import, you should disable any virus
    protection which may be present on either
    machine.  This can slow down the import
    considerably.

3.  On the machine with the VSS database, you should
    be running SourceSafe 6.0c, plus the following
    hotfix from Microsoft:

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q323917

    The hotfix is also available at

http://www.sourcegear.com/vault/downloads/vss_60c_hotfix.zip

    Do not use SourceSafe 6.0d.

4.  Do not continue to use your SourceSafe database
    during the import.  In fact, it is best if you
    run the import on a backup copy of the database,
    not on the copy you usually use.

5.  Be sure to run the SourceSafe 'analyze' utility
    on your database before doing the import.

6.  Make sure the IIS doesn't get confused and kill
    ASP.NET during long operations.  In your
    machine.config file, look in the processModel
    section and find the setting called
    responseDeadlockInterval.  The default value is
    three minutes.  We recommend changing it to at
    least an hour.

7.  In Vault's Web.config file, there is a setting
    called executionTimeout.  We recommend setting
    this timeout to at least an hour.

8.  In Vault's Vault.config file, there is a setting
    called SqlCommandTimeout.  We recommend setting
    this timeout to at least an hour.

9.  Using the Vault Admin tool, select the Server
    Options tab.  Verify that the default setting
    for IIS File Upload Limit is appropriate for the
    data in your repository.  If you have very large
    files, you may wish to increase this setting.

10.  You should make sure that IIS is configured to
     allow anonymous access to the VaultService
     directory.  This does not compromise security,
     as you are merely instructing IIS to allow
     Vault to handle its own authentication.

11.  Before doing the import, you may wish to review
     your VSS database and purge any items which
     have been deleted and are no longer needed as
     part of a past label.

12.  Note that in Vault 1.1, importing labels can be
     extremely slow.  You may wish to import only
     those labels which you actually need.  This
     suggestion does not apply to Vault 2.0.

--
Eric Sink
Software Craftsman
http://software.ericsink.com/

 
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Matt White
Sent: Tuesday, December 16, 2003 5:32 PM
To: [email protected]
Subject: [vault-list] VSS Import Errors

I posted a long rant last night which never made an appearance on the
list cos it exceeded the 60K limit.....
 
Anyway, after 9 hours processing last night, I can happily say that
everything failed to import, so I was left with an empty Vault
repository and nine hours of my life I'll never get back....
 
But having trolled the log file (can you keep display and error/success
count on the VSS import form? Would have saved me a lot of time last
night) that the importer creates, there is the same error over an over
again... :
 
Beginning Export.
Begin Export....
 
Memory used: 35872768.
Created  ($/Redgum/Testing) at 4/2/2001 1:30:10 PM
Change set type: CreateFolder
Adding to transaction: $/Redgum/Testing - $/Testing
Server unavailable for transaction end
Transaction failed
Transaction failed
**Failed** - Error trying to commit. Exception of type System.Exception
was thrown.
Trace:   at VSSImport.WizardForm.a(String A_0, DateTime A_1, Int32 A_2)
12/17/2003 10:18:47 AM - Unable to commit for 4/2/2001 1:30:10 PM -
$/Redgum/Testing - Created . Refreshing SourceSafe connection...
Opening: D:\SourceSafeData\Redgum\srcsafe.ini
User: admin
VSS database open: True
 
12/17/2003 10:18:47 AM - Refreshing connection to the Vault server.
 
Logged out of the Vault Server.
Connected to Vault.
Server unavailable for transaction end
Transaction failed
Transaction failed
**Failed** - Error trying to commit. Exception of type System.Exception
was thrown.
Trace:   at VSSImport.WizardForm.a(String A_0, DateTime A_1, Int32 A_2)
12/17/2003 10:19:18 AM - Unable to commit for 4/2/2001 1:30:10 PM -
$/Redgum/Testing - Created . Refreshing SourceSafe connection...
Opening: D:\SourceSafeData\Redgum\srcsafe.ini
User: admin
VSS database open: True
 
 
etc, etc......
 
Vault itself seems to be running OK - the Client and Admin tools both
connect OK... the SQL database is online and accessible. 
 
The machine being used for the upsize is a 1.1Ghz Celeron, 1Gb RAM,
Windows 2K fully serviced packed and freshly built from scratch
yesterday. Only applications installed on the machine are VB6
Enterprise, VSS 6.0c, Vault Server, Vault Client and Vault VSS Import
Tool, SQL Server. Destination database is MSDE SP3, again freshly
installed yesterday. Only database attached (apart from the default 4)
is the Vault DB. Everything else is local, VSS Database, IIS, SQL
Server, the works. 
 
I'm using the SUE edition (for the import only - once I'm happy with the
import, I'll roll out the dev licences I need), so I don't know if the
problems are related to the restricted user count - there are about 10
users (past and present in the VSS database, of which 5 were active in
the VSS project branch I'm importing) or what.
 
Any ideas?
 
Matt
 
____________________________________________
Matt White
Software Engineer [email protected]
<mailto:[email protected]>  Advanced Publishing Systems Pty Ltd
Phone: (03) 9940 1441 Fax: (03) 9940 1458 
	
420 Victoria Street
Brunswick VIC 3056 	
 

_______________________________________________
vault-list mailing list
[email protected]
http://lists.sourcegear.com/cgi-bin/mailman/listinfo/vault-list