You are viewing limited content. For full access, please sign in.

Question

Question

RepositoryUUIDUpdater.exe crashing

asked on December 15, 2014

Hi All,

I am running this utility to copy a database to another server.

It keeps crushing.

The logs show up to this:

 

2014-12-15 21:10:11.464 Repository UUID update process begins
2014-12-15 21:10:11.464 DBMS Type: Microsoft SQL Server
2014-12-15 21:10:11.464 Server: (local)
2014-12-15 21:10:11.464 Database: LF-TEST-Repository2
2014-12-15 21:10:11.464 Authentication: Windows Authentication
2014-12-15 21:10:11.464 New Repository UUID: 6b515714-1369-4490-a292-ca58ce919f44
2014-12-15 21:10:11.567 Current UUID of the respository: ed6f709c-274b-4cc8-a52b-51e526eda7b1
2014-12-15 21:10:12.247 Update Table: account_cache - Columns:  account_sid
2014-12-15 21:10:15.607 Update Table: account_security - Columns:  sid
2014-12-15 21:10:15.995 Update Table: active_doc - Columns:  tocid
2014-12-15 21:10:16.007 Update Table: activity_log - Columns:  asn

 

I check the amount of rows in the table activity_log and it is 1896691.

I let it run all weekend but is still the same.

I was running this application from a PC inside the network.

I just move it to the server where SQL is installed and although it seems to run faster for the first 4 tables. it still crashes at the same stage.

 

It doesn't show any errors messages, the application just gets "grey". 
There is only one error on the event viewer and is:

 

An error occurred:
An error occurred in repository TEST-Repository2: Unknown error.    at AuditDBService.RepositoryValidator.validate(LaserficheInfo& info, DBMSType type)
   at AuditDBService.Service1.GetImporter(ConfigInfo info)
   at AuditDBService.Service1.ImportTimerElapsed(Object o)
This was caused by:
Unknown error.    at LFSO80Lib.LFConnectionClass.Create(Object Database)
   at AuditDBService.LfConn.LFSO.Login(LaserficheInfo lfInfo)

 

 

Could this be because Audit Trail was still running? Laserfiche server is stoped. 

Should I stop all services or have them all running?

 

Thanks

 

Gian

 

0 0

Answer

SELECTED ANSWER
replied on December 15, 2014

Unregister from the LF admin console

Detach from SQL

Copy the db

Attach the copy to another instance

Run the UUIDupdater on the copy

You can attach the original back to SQL and register it again.

Once you have run the UUIDupdater on the copy, you can treat the copy like another SQL db for another LF repository.

1 0

Replies

replied on December 15, 2014

Are you running the updater on a copy of the db?  Are you also running/generating a report in the Audit trail manager?

Unregister the original repository first from the LF admin console.

Once unregistered, detach it from SQL.  Copy the SQL db, attach it to another instance on another machine, then run the updater. 

You can attach the original repository and register it back to the original machine while the Updater is running on another machine.

0 0
replied on December 15, 2014

Hi Raymond,

I manage to do what I wanted witch is an exact copy of the repository in another server.

But I wan't to have both servers running.

I restored the database from the original repository into the new one. And I copy the repository files across as well.

I talk to our VAR and he clarify that he did this before without need to run the UUIDUpdater utility.

I register the destination repository and seems to be working fine. With no need to update the database.

I may have misunderstood what this utility is for.


Thanks

 

Gian

 

0 0
replied on December 15, 2014

You cannot run two identical copies.  You will need to run the UUIDupdater on the second one. It may work now but you will run into issues in the future if this is not done.

0 0
replied on December 15, 2014

Ok is good to know.

So, in order to do this are this the steps?

1-Detach original repository

2-Stop all laserfiche services on destination repository.

3-Run UUIDUpdater

If is not could you please list all steps?

Thanks


Gian

0 0
replied on December 15, 2014

The only time you need to change the UUID is if you intend to run multiple copies of the repository on different machines.  If you are just moving your Repository DB(s) to a new SQL server, there is no need to run the UUIDUpdater.

0 0
replied on December 15, 2014 Show version history

Sure, but neither can it hurt and it gives you the option to move the repository back to the original machine should that need arise.

It will also avoid issues like this.

1 0
replied on December 15, 2014

Hi Raymond,

That is what I wanted.

Becouse I am planing on keeping both repositories in use. Is not a MOVE but a COPY.

 

Thanks!

 

Gian

0 0
replied on February 2, 2016

I encountered this problem this morning and thought I would share my results.  My log looked exactly like Gianfranco's.  It took almost four hours to complete while it appeared to be crashed (not responding).  My database is not small, about 15GB.  If the RepositoryUUIDUpdater.exe process is active, just let it run.

 

Sorry to resurrect an old thread.  

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.