November 25, 2016 at 11:39 #14272
I have been having some odd issues lately with vLookups in my SP 2013 on premise environment.
I am using the installer version, but without the app. Minimal dl strategy is off etc, and there are no master page modifications, pure vanilla sp.
2 things happen, very irregularily but frequently so:
1. Prefill in child works 50% of the time. We pass the ID of the item to a lookup field and hide it, but it decides to mostly just work when the form is not opened in a dialog. As our users prefer working with the vlookup from the edit form this is a bit of an issue. Are there any particular things worth looking for?
2. vLookups often don’t render on first page load, the single line of text fields don’t get converted to vlookups until a page refresh.
Both these issues have been encountered sporadically by several users, and tested for in newest firefox, chrome and ie 11.
Is there some good place to start troubleshooting this, or any idea what to tweak to get it working better? 🙂
November 29, 2016 at 19:42 #14292
Sorry for the delay. I haven’t had this reported before. Are there more than 5000 items in the child list? – this could make it run a bit slower, but should still work.
If you are able to force this error – do you see any errors in the developer console (hit F12 > Console)?
Are you sure you have removed any old version of DFFS that may have been loaded using the old “CEWP” installation method? – you can try editing the form and look for the old CEWP’s (please note that the new installer uses it’s own CEWP’s, but there should not be double up.
Do you see this error in one list / form only, or does it happen in different forms?
December 2, 2016 at 16:27 #14325
It seems to exclusively happen on the edit form, and not the disp form.
Only way to “force” it seems to be letting clearing the browser cache and loading the full jquery and all other files on the opening of the edit form. That still does not always work either, so I am quite stumped as to the root cause.
All loads of the edit form after this occurs succeed and refreshes work 100% of the time. Until a day or so later it will re-occur to the same user.
It is not what I would call the end of the world kind of error, but it is quite irritating for the users who after filling in the fields at the top of the form need to save and re-edit the file to add items to the vlookups.
How it looks in the UI attached.
The console does not reveal any errors when it happens unfortunately. The child list contains very few items at the moment, and per parent item there might be 1 – 5 items per vlookup in the worst case scenario in the future. So I am not worried about the capacity aspect of this.
Is there a way to add a debugger to the vlookup files? See if they are loaded properly? The rest of the form behaves as it should, even though it is only using tabs and a little bit of css on the labels to make them bold.
December 5, 2016 at 20:41 #14346
Are you using the latest version of DFFS and vLookup in the child list?
Will other values (for example a text field) fill correctly? – if so, does the lookup column you try to fill contain a lot of values? – maybe it loads to slow and vLookup tries to autofill it before it it’s ready?
If you don’t need this to be a lookup column, you can pass the ID (or the _DFFSID) to a text field and use this as “connection” for vLookup.
Which version of DFFS and vLookup are you using? – not sure it does any difference, but is it the latest one (November 28, DFFS v4.4.2)?
Do you have a lot of other columns in this form (people pickers and lookup columns in particular)? – these may slow the loading of the form. Not sure if it helps, but look at the Misc tab in DFFS and defer the loading of DFFS 500 milliseconds to see if this might be a timing issue.
December 6, 2016 at 09:53 #14356
Issue 1 is mostly resolved now, we reorganized the fields in the form and now I have not seen any issues with the passing of the ID to the lookup column any more since then. Sot that one I think we can ignore for now 🙂
Issue 2 has not re-occurred for me for a while, we are using the version from before nov 28th version, so very little changes on the vlookup front to justify the ugrade I think. If it ends up not working Ill do it of course, but I think the delayed loading might solve the problem due to the way the form is using 3 people pickers before the vlookups. I will try the delayed load and see if this might resolve it, thanks for the tip 🙂
December 9, 2016 at 18:50 #14434
December 21, 2016 at 10:12 #14609
After the delayed load tweak I did not hear of any more occurences of the issue. I also uploaded the newest version 2 days ago, and since then also no more bug reports 🙂
So problem resolved, thanks again! 🙂
You must be logged in to reply to this topic.