Re: FW: VSS Import Errors

matt:

can i assume the machine running sql 2000 / msde 2000 does not have msxml 2?  if so, then you are in a little bit of trouble here.  i'm not sure how to correct the issue, but msxml4 is not compatible with sql 2000.*

sorry, but you'll have to get sql server running with msxml2 in order to correct things.  if i've mis-diagnosed the problem, please let me know.

jeff clausius
sourcegear corporation

-------------------
* - from a groups search - 

There is no way to get SQL Server itself (FOR XML, OpenXML) to make use of 
MSXML4.0.  SQL Server uses the version-dependent GUIDs that point to MSXML 
2.6.  Also, note that MSXML4.0 is not an equivalent replacement for 
MSXML2.6 (see the MSXML documentation for a complete list of differences 
between MSXML4.0 and previous versions).

<snip>

Hope this helps,

Michael Brundage
Technical Lead, XML Query Processing
WebData XML Team, Microsoft
-------------------
source - 

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=0epkjOzuBHA.1988%40cpmsftngxa07&rnum=3&prev=/groups%3Fq%3DMsxml4.%2B%2522sql%2Bserver%2522%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3D0epkjOzuBHA.1988%2540cpmsftngxa07%26rnum%3D3


*********** REPLY SEPARATOR  ***********

On 12/18/2003 at 7:52 AM Matt White wrote:

>Forgot to attach a bit of the log file, just in case there's a better
>fix for my problem...
>
>----12/17/2003 7:27:55 PM    sgvaultsystem--()--
>	System Started
>	Version 1.2.3.758
>	Cache Level = 1
>	DataBase Buffer Size = 256
>	LogFile Path = C:\WINNT\Temp\sgvault
>	Log Level = Quiet
>	Archive Log = Weekly
>	ReverseDNS Lookup = True
>	Maximum HTTP Request Length = 102400
>	Overwrite Log on Startup = False
>	Session Timeout = 4320
>	SGVault Working Directory = C:\WINNT\Temp
>----12/17/2003 7:28:00 PM    admin--barry(192.168.10.35)--SSL Disabled
>	Login
>----12/17/2003 7:28:25 PM    admin--barry(192.168.10.35)--SSL Disabled
>	Failed to load Msxml2.dll.
>----12/17/2003 7:28:25 PM    admin--barry(192.168.10.35)--SSL Disabled
>	VaultServiceBase.VaultResponseAddFolder returned: Success
>----12/17/2003 7:28:25 PM    admin--barry(192.168.10.35)--SSL Disabled
>	EndTxFailDBInsert
>
>Matt
>
>-----Original Message-----
>From: [email protected]
>[mailto:[email protected]] On Behalf Of Matt White
>Sent: Thursday, 18 December 2003 07:48
>To: [email protected]
>Subject: FW: [vault-list] 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
>_______________________________________________
>vault-list mailing list
>[email protected]
>http://lists.sourcegear.com/cgi-bin/mailman/listinfo/vault-list
>_______________________________________________
>vault-list mailing list
>[email protected]
>http://lists.sourcegear.com/cgi-bin/mailman/listinfo/vault-list