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

Question

Question

Best way to update Template info??

Laserfiche
Updated February 3, 2014
asked on February 3, 2014

 So I have a customer that purchased a new banking software, so now their customers all have new account numbers...so what they'd ultimately like to do is Update the template with the new account number (use the old one to reference the new one), and then re-create the folders.  I know this can be done with Workflow, but they don't have Workflow, so I'm wondering if it's easier to do it on the backend using a SQL Query, or using Quickfields and RealTime Lookup?  I'm also considering importing the data into our system and using Workflow to do it and then sending them the data back.  Looking for suggestions as to what might be the cleanest way to do this.

 

Thanks!

0 0

Answer

SELECTED ANSWER
replied on February 3, 2014 • Show version history

We generally don't recommend updating the SQL database directly; given the risks entailed and the bypassing of reporting and security. As Blake mentioned, if you opt for this route, be very careful with your query and make sure you have it backed up. The optimal solution is to conduct this operation in Workflow.

 

Update to clarify Miruna's comment. If this is a one-time operation and you understand the risks involved, then yes, updating the SQL database directly is simpler. My comment is based on general recommended practice, particularly if the operation is not a one-off, that doesn't require knowledge about the Laserfiche Server table structure in SQL.

1 0

Replies

replied on February 3, 2014

I would think that doing a custom SQL Query with their database would be the way to go, but I would suggest you be extremely careful and make sure that you are targeting the exact field as a broader match query might replace other items with the same values. In reality getting them to go to purchase Workflow would be of the most benefit for the situation and I'm sure would help them with other processes they have.

1 0
replied on February 3, 2014

So they have Quick Fields and not Workflow? Interesting setup.

 

You can set up a quick fields session to do a search and grab in documents from the repository. 

 

What you might want to do is use a tag to help process these documents. Do a search and apply the tag to everything, then add in that tag to the search and use that for your Quick Fields session.

 

Have Quick Fields preserve the original files and to remove the tag. Use the lookup to get the new value to change and you're done...Set it to the document class information and then run the session. It should be able to be stopped and continued at any time since we use the tag to indicate those documents that have not been processed yet.

0 0
replied on February 3, 2014

We have had similar needs in the past.   You can use quick fields or workflow,  however it can take a long time to update documents using those tools, when you are doing a mass change of documents. We tried both of those methods and for us,  the best option was to write  a tool to update the SQL database directly customized for the specific need. 

0 0
View 1 previous reply
replied on February 3, 2014

They have SQL guys on staff...but they don't know Laserfiche...what do they need to know in order to do this through SQL? 

0 0
replied on February 3, 2014 • Show version history

Let me add my vote to doing this directly in SQL too. To state the obvious, make sure you have valid backups and turn off the LF Server before running the query.

 

The entry IDs are stored in the TOC table. The fields corresponding to each document are in the PROPVAL table.

0 0
replied on February 3, 2014

Miruna...are you suggesting SQL is the best way to do it (as another Laserfiche member had discouraged the practice)??

 

Thanks!

0 0
replied on February 3, 2014

Yes, based on the fact that this is a one-time update and the overhead required by each of the other LF products, I would do it in SQL (with backups and testing). In order of overhead required and performance delivered, I would rank your options like this:

  1. Direct SQL query (Pro: fast. Con: requires knowledge of SQL backend; needs to be done with the LFServer off; is not audited; unsupported if anything goes wrong)
  2. SDK (Pro: goes through LFServer, so it's audited; does not require backing up the database or stopping the LF Server. Cons: requires knowledge of LF SDK, not as fast as direct SQL update)
  3. Workflow (Pro: easy to set up, no programming required. Cons: Probably slow since WF will have to open a connection to the data source, read the matching numbers and close the connection for each document it updates).
  4. Quick Fields (Pro: easy to set up, no programming required. Con: Slow - in addition to opening/closing connections to the data source for each document like WF, the document is also exported out of LF and imported back in).

 

So, yes, if you test your queries properly and back up the DB, SQL is the way to go. The safer and relatively fast way is through the SDK. I'd only use WF or QF if time spent updating all documents is not an issue.

 

Additionally, if your repository is under 50000 documents or so, QF and WF will be just fine.

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

Sign in to reply to this post.

Details
Related Posts
Loading ...