9 Replies Latest reply on Jun 2, 2010 4:07 AM by Kris Jankiewicz

    Replication file list?

    Kris Jankiewicz

      I'm trying to remove a replicated vault but haven't been able to because a single file won't replicate. No errors and nothing in the logs. The archive status just shows 1 existing file that hasn't replicated yet. I've resceduled the replication task over and over but the file remains unreplicated.


      Does anyone have a way to list the files that haven't replcated between source and target servers? I tried using a query on the ArchiveServerStored table but haven't gotten any results showing me a file not replicated. Could this file be refereced elsewhere? If I could decrypt the stored procedure that gets the results for the archive status window, then I could find where the script is coming up with that 1 file.


      Maybe the PDM guys should add a button in the Archive Status window that allows you to view the files waiting for replication or to use the report generator.



        • Re: Replication file list?

          If you right mouse on the "Archive Status" Icon in the vault tree of the Administration tool and "Show Missing Files", you will get a list of files that have not replkicated.

            • Re: Replication file list?
              Kris Jankiewicz

              Thanks. I don't know how I missed that.


              When I selected "Show Missing Files" it asked it I wanted to only see the first 99 files. I selected No. Notepad opened up showing a huge file list (150,000+). I opened up the find window and typed in the name of the remote server. Found it.


              But now....why won't it replicate? I'm going to try taking it out of the vault and puting it back in.

                • Re: Replication file list?

                  Try having someone that has a local view to that replicated archive server try to get that version of that file. This should do an "on demand" replication of that file on the replicated vault.

                    • Re: Replication file list?
                      Kris Jankiewicz

                      Now I have a problem. I can't delete the file and put it back in the vault because it has history that is important. I'm going to have to find out what the replication problem is.


                      In the file list, this is the entry that points to the 1 file that won't replicate (some information replaced with <>)


                      File,\Eng Drawings\<division name>\2009681.SLDDRW,6,16,<server>-PDM,No,58855


                      Doing a "Get Latest" won't solve the problem because I'm guessing that the "6,16" refers to the file version since the latest version of this file is 16. So it must be file version 6 that is causing the problem. I'm going to open the history and try doing a "Save" of that version to the desktop.

                      • Re: Replication file list?
                        Kris Jankiewicz

                        I did a "Save" from the history window on each of my pdm servers. The file was immediately save to the desktop which means it didn't have to replicate from another server. I opened the drawing and it was identical on all my servers.


                        I checked the "Archive Status" again and now it showed 2 files needing to be replicated. I scheduled a replication, waited and checked the status again. Still 1 file to be replicated, so I check the "missing files" and it's the same file and version as before.


                        *scratches head*

                        • Re: Replication file list?
                          Kris Jankiewicz

                          Ok. Here's what I found.


                          I opened up windows calc and converted the document id of that file from decimal to hexidecimal (58855 = E5E7)


                          On the target server (the server I want the file to replicate to), I opened up windows explorer and navigated to the vault folder. From there I took the last hexidecimal from the converted document id (7) and opened that folder. Then I found the 0000e5e7 folder and opened that up (so the full path was "X:\Vaults\<Company>\7\0000e5e7")


                          In there I found 14 drawing files. File versions 6 and 7 were missing.

















                          Then I opened the index.xml and saw this:


                          <?xml version="1.0"?>
                          <index version="9.0">
                          <version id="1" uid="98833" date="2009-05-20 21:53:48"/>
                          <version id="2" uid="99141" date="2009-05-22 15:54:48"/>
                          <version id="3" uid="99154" date="2009-05-22 17:41:44"/>
                          <version id="4" uid="99165" date="2009-05-22 17:41:46"/>
                          <version id="5" uid="99182" date="2009-05-22 17:47:48"/>
                          <version id="6" ref="5" uid="101518" date="2009-05-22 17:47:50"/>
                          <version id="7" ref="5" uid="101757" date="2009-06-08 14:57:52"/>
                          <version id="8" uid="101770" date="2009-06-09 15:46:44"/>
                          <version id="9" uid="107901" date="2009-06-30 16:45:24"/>
                          <version id="10" uid="116439" date="2009-07-06 18:44:20"/>
                          <version id="11" uid="116736" date="2009-07-08 13:33:36"/>
                          <version id="12" uid="116759" date="2009-07-08 13:58:50"/>
                          <version id="13" uid="116807" date="2009-07-08 14:31:50"/>
                          <version id="14" uid="118715" date="2009-07-14 14:13:02"/>
                          <version id="15" uid="118726" date="2009-07-14 14:27:38"/>
                          <version id="16" uid="118729" date="2009-07-14 14:40:40"/>


                          Versions 6 and 7 are "references?" (I'm guessing) of version 5.


                          Then, I did the same thing but on the source server. There were these 3 files:






                          The index.xml file contained this:

                          <?xml version="1.0"?>
                          <index version="9.0">
                          <version id="5" uid="99182" date="2009-05-22 17:47:48"/>
                          <version id="6" uid="101518" date="2009-06-08 14:57:50"/>
                          <version id="16" uid="118729" date="2009-07-14 14:40:40"/>


                          Now I'm confused. Why does the xml file on the target server show version 6 with a ref="5" and the xml on the source server not? Does anyone know exactly what the ref means? Both versions (6 and 7) where just straight check-out and check-in. Nothing special happened.


                          Also, why is file version 16 show in the xml file on the source server and the file not exist, but file version 10 does?


                          Are there any vault guru's out there that can explain this?

                            • Re: Replication file list?
                              Todd Puckett

                              I would start by contacting your VAR.  They can get you connected to some excellent SolidWorks Technical Support Engineers.  I have used them on many occasions for situations like this that I could never have figured out on my own.

                              • Re: Replication file list?
                                Jeremy Feist

                                I'm not sure why they would be different - we run one server, so no replication for us.


                                but the I can shed a little light on the "ref" part. because those are SW files, EPDM can recognize when the new version is identical to the previous one and will put in a pointer, rather than saving a new version to the archive. this saves on disk space, but still lets you pull up a copy at any version you like.



                                • Re: Replication file list?
                                  Kris Jankiewicz

                                  While waiting for our VAR and SolidWorks to find a solution to this problem, I took a copy of the production database and put it in a virtual environment to poke around. I ran a trace on the on SQL server on our vault database. I then tried to remove the replicated vault from the remote server. The only query that sparked interest was:


                                  Exec Arc_GetUniqueCount 5


                                  "5" is the ID of the remote server and "2" is the local server. So, what the stored procedure return? Two unnamed colums. The first column had a value of 8 and the second 0. I'm guessing this means that the database thinks there are 8 unique files on the remote server not on the local server. So why does the archive status show only 1 file not replicated?


                                  I took one step further and changed the archiveid from 5 to 2 in the archiveserverstored table to make version 6 of the file file that won't replicate exist to the local server. I also removed the version 6 XML reference on the remote server. The archive status now showed 0 files needing to be replicated. All existing, deleted and system files where 100% on the local server. I then tried to remove the replicated vault on the remote server and got the same error message:


                                  "The vault contain files that are not yet available on any other archive server and can therefore not be deleted".

                                      --Jeez! Who writes these error messages??!! Hopefully SolidWorks isn't outsourcing to China. LOL!!


                                  and after clicking OK to that message, I get this one:


                                  Could not remove vault '<name of our vault>' from the archive server.

                                  Error Description: The specified Archive Server operation was invalid in the context.


                                  How fun!


                                  I hope the SolidWorks guys don't get mad about me digging so deep on my own. I'm just really frustrated with all the bugs in their software! You'd think with the amount of money we spend of this stuff it would be a bit less buggy. The information I'm posting is informationaly only, for those of you in the same or similar boat.