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

Question

Question

Laserfiche SDK: Adding/Inserting info into field that allow multiple values.. (blank field value)

asked on August 9 Show version history

We have a 3rd party product (GEODOCS by Docunav) that inserts data into a multiple value field we use called Storm_Mains. We get blank fields that show up as position 0 in the propval SQL table for that field and then the data is added or inserted at position 1. I think the process should work where the placeholder pos 0 in table propval that has a blank or null value should be replaced by the new value and it should be the new pos 0 in the table.

We can see this when we go into Laserfiche and pull up the metadata, where there is a blank in position 0 (see below).  As well, you can see the same entry in the propval table so you see we are working with the same data (also below). 

 

 

You can see how Laserfiche handles the field and you notice that there is no value in the Storm_Mains field, just a number. Technically, it is showing the user position 0 (which is blank) and that there are 5 additional entries. 

 

 

Here is an example of multiple entries with the same problem as well as my EntryID of 644091 that I have noted above. In each instance, position 0 being a blank has created a problem with how we see the data.

 

The simple fix is to delete the blank entry from position 0 and the SQL table will then re-position the entries as 0 through 4 for the 5 entries versus 0 through 6 for the blank and then the 5 entries. I would like to know if there is a way to avoid this in the first place and replace the value at position 0 whenever a new entry is added via the 3rd Party product versus just adding a new entry at position 1 and leaving the blank. From what I can tell in the table propval, all fields have a value in the table. They are blank if there is no entry and they have data if there is a value. 

ADDED NOTE: This only became an issue when we moved to Laserfiche 10.x because the previous version (we tested it), hides the blank spaces in the table. The new version does not. That is what exposed the issue, but the issue existed prior to 10.x, it just was exposed in 10.x.

I am new to the LF product so I am not familiar with how the 3rd party integrates but I assume it is via the SDK.

 

Thanks

Roger Landers

 

 

0 0

Answer

SELECTED ANSWER
replied on August 9 Show version history

Yea, I think the problem is how they are using the SDK rather than a problem with the SDK's underlying functionality.

To test, I added a multi-value field to my document with no current value. In the database I confirmed that it is stored the same as in the original post.

Next, I ran some SDK code to update the field.

DocumentInfo doc = Document.GetDocumentInfo(entryId,session);
FieldValueCollection fvc = doc.GetFieldValues();
                        
List<string> valueList = new List<string>();
valueList.Add("1");
valueList.Add("2");
valueList.Add("3");
            
object[] values = valueList.ToArray();
            
fvc.AppendValues(fieldName,values);
doc.SetFieldValues(fvc);
doc.Save();

And the end result is as expected; only my new values show up and the blank value has been removed.

My guess is that their code builds the object list by retrieving and appending to the existing values, and they did not account for the fact that it might be "empty" rather just than NULL.

The SDK isn't really "allowing" odd behavior, it is simply storing the list of values exactly as it was received from the application.

2 0

Replies

replied on August 9 Show version history

Can you clarify how the blank value ends up in position 0? is DocuNav editing the sql table directly? LF applications should remove any blank values when setting multivalue fields (unless you are using multivalue field groups, see here for more information)

1 0
replied on August 9

The storm_mains field is a multi-value field. We are not using multivalue field groups. From my understanding, the 3rd party uses the SDK for any updates to the LF SQL data. Seems like a broke in the SDK or using the wrong task to update the table (insert versus add or something like that). 

0 0
replied on August 9 Show version history

If they are using the SDK, they shouldn't be doing any insert/update to SQL directly. If they are updating a multivalue field the tasks would essentially just be append or replace (add another "row" or replace everything).

If there's no concern about overwriting any existing data, it sounds like they should just be taking all of the values, putting them into an array, and updating the field with the array.

Perhaps they are trying to append their values to the existing values and not omitting anything that is empty?

I think what Robert is trying to determine is how you're ending up with a blank value to begin with because, like he said, the built-in processes are designed to remove those automatically.

1 0
replied on August 9

I think the crux of the issue is that the SDK is allowing this odd behavior to occur. If the table propval sets all fields as position 0 in the table until they are filled in, then it should be accounted for via the SDK when it is the first entry into a field and is replacing the placeholding position 0 for a valid entry. 

0 0
replied on August 9 Show version history

A multi value field is filled using a string array.  I am wondering if the Docunav code is not accounting for the fact that arrays are zero based and thus leaving item(0) of the array null when they populate/update the field.

 

Because of the new field groupings, a null value within a multi value field is now an accepted value to display (why you now see it).

 

EDIT:

After playing with adding this through the SDK, I am not sure what you have going on.  On my system, I can see the empty values in the DB PropVal table like you show, but in my client (10.3.1), the blanks are not displayed unless the field is part of a field group.

1 0
SELECTED ANSWER
replied on August 9 Show version history

Yea, I think the problem is how they are using the SDK rather than a problem with the SDK's underlying functionality.

To test, I added a multi-value field to my document with no current value. In the database I confirmed that it is stored the same as in the original post.

Next, I ran some SDK code to update the field.

DocumentInfo doc = Document.GetDocumentInfo(entryId,session);
FieldValueCollection fvc = doc.GetFieldValues();
                        
List<string> valueList = new List<string>();
valueList.Add("1");
valueList.Add("2");
valueList.Add("3");
            
object[] values = valueList.ToArray();
            
fvc.AppendValues(fieldName,values);
doc.SetFieldValues(fvc);
doc.Save();

And the end result is as expected; only my new values show up and the blank value has been removed.

My guess is that their code builds the object list by retrieving and appending to the existing values, and they did not account for the fact that it might be "empty" rather just than NULL.

The SDK isn't really "allowing" odd behavior, it is simply storing the list of values exactly as it was received from the application.

2 0
replied on August 9

Very cool. I appreciate the great description. I will share this with our channel to see if they can look at your breakdown to figure out where the problem lies. 

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

Sign in to reply to this post.