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

Question

Question

SDK timing issue - "Argument 'index' is not a valid folder"

SDK
asked on May 8, 2015

I had this come to me from a client who has a custom SDK program that creates a folder then populates it with items. It's been in production for a while and most of the time it just works, but occasionally during busy times it errors out. My client has been very diligent in putting in debugging try-catch's to isolate the error but he' stumped as how to knock this issue out. 

 

This is a code snippet:

Try
                ParentFolder = DB.GetEntryByPath("\Returns")
                Try
                    ChildFolder.Create(DocFields.FieldByIndex(6) & "-" & _
                        DocFields.FieldByIndex(5), ParentFolder, False)
                Catch ex As Exception
                    ChildFolder = DB.GetEntryByPath("\Returns\" & _
                        DocFields.FieldByIndex(6) & "-" & DocFields.FieldByIndex(5))
                End Try
            Catch ex As Exception
                Doc.Dispose()
                TempString = ex.Message & vbCr & vbLf & _
                    "Getting move to folder in CreateReturn()"
                MsgBox(TempString)
                Exit Sub
            End Try

 

So at high load times, it sometimes returns the message:

Argument 'Index' is not a valid value

Getting move to folder in CreateReturn()

 

They thought it may be a licensing issue but that I said that didn't make any sense to me as they haven't disposed of the connection by this point, and other communications with the LF server have already worked before it gets to this point. I suspect it's a timing issue as it's still trying to create the parent folder above this point and it's failing because it's not actually there yet.

 

So my question is what is the best way to determine if a sdk request has been completed by the  server before moving to the next step?

0 0

Replies

replied on May 8, 2015 Show version history

Chris - Not a direct answer to your question but the first thing that pops out is that perhaps the client should store the Create FieldByIndex(n) parameters to variables earlier in the routine instead of referencing the document field values with several property calls.  (Perhaps the reference to the original document to get the field values is not available during high volume times?)

I would try to gather all of the values as variables for folder creation earlier and then reference the variables instead of having to go back to the original document several times to get the values. 

Dim folderName As String = DocFields.FieldByIndex(6) & "-" & DocFields.FieldByIndex(5)
Dim existingFolderName As String = "\Returns\" & DocFields.FieldByIndex(6) & "-" & DocFields.FieldByIndex(5)

Try
    ChildFolder.Create(folderName, ParentFolder, False)
Catch ex As Exception
    ChildFolder = DB.GetEntryByPath(existingFolderName)
End Try

Just a thought...

 

2 0
replied on May 8, 2015

I don't see how this particular error (Argument 'Index' is not a valid value) could be thrown in this code, it's a VB error for collections that the LF SDK wouldn't throw. It's not a problem with the FieldByIndex calls because internally they just map index to field name and call FieldByName. Is this a multithreaded application with multiple threads using the LF SDK? maybe there is a thread safety issue and the error message is a red herring.

2 0
replied on May 8, 2015 Show version history

Robert and Cliff,

 

The customer would like to thank both of you for your feedback. He's going to investigate the thread safety aspect of it because it is a multithreaded application.

 

He's also going to see about implementing Cliff's solution in the short term as well since less calls to laserfiche would probably help reduce the load which may lessen the occurrence of thread safety issues. 

 

If/when he's able to isolate this he'll let me know so I can update this thread in case someone else has a similar issue. 

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

Sign in to reply to this post.