That's pretty weird.
Two thought come to mind though whether they are at all relevant I have no idea at this time.
Is that column null throughout or are some of the records correctly populated?
Firstly the Preview is probably set to only review a restricted number of records in the report/database file. I can't think of anything to explain the difference is all records in the full set are null values BUT it is a small processing difference to be considered.
The second thought is to use the Change Source button and then re-select the external lookup file and see what happens.
I would be tempted do that using copies of the model and the external lookup xls file.
Is this the first time you have accessed the 10.5 model? Or has it already been through 13.4 and so exists as a .dmod file?
There were some quite significant changes between 13.4 and 13.5 but none of them that I can think of bring this sort of problem so far as I recall.
Hello Grant! Thanks for the reply.
And as I mentioned, I don't relish the idea of having to redo every model/project/link/process we have here. Already finding multiple instances of things not working that I have to delete and do over and then they work fine. Most unwelcome AND very very inefficient in addition to the slower speed and numerous extra steps to get to plenty of things that used to be much more quickly accessible.
Not a fan so far. I have elected to skip pretty much everything that's not working as I don't have time to redo it all right now. Much more important things have to get done. Can not fathom how our less skilled users will fare with this new version.
In the past couple of years I have done some testing for people upgrading from V10 (and earlier in some cases) to V13 and V14 and most models have just worked.
I don't think there were any with external lookups but there were a few with other relatively challenging features deployed. Unless there had been a fundamental change or (extremely rarely) feature deprecation (usually because no one was known to be using the feature!) there were no problems.
Most issues that do arise seem to relate to the variability of PDF files and some cases of Excel incompatibilities but those are most commonly to do with Windows/Office/.NET changes that may not help when using older versions of Monarch (7, 8 and so on.) or some versions of Excel.
10.5 was a sweet spot of development in its day but the available technology and the needs of some customers was moving on.
For what it's worth I much prefer V14 to V13 but making that move may not be an option for you.
Hello again Grant!
Just so you know, I wouldn't even waste time complaining about PDF or EXCEL accessory, as in after the fact!, behavior. I might as well scream straight at Microsoft. HA!
But...just since my last update, we have a model that won't break pages for new keys when printing from a SIMPLE text file with an x.mod we used weekly. After turning it off and then turning it back on, the working fix is to delete the key and THEN put it back. Time well spent!
Is that time well spent because it helped with your external lookup problem or the problem you were having with page breaks?
If you are still having a problem, have you tried changing the data type of store field? If it was numeric, did you try switching it to character or visa versa?
If re-applying the link is also the solution for the original problem it is something that has been seen before but not specifically in your scenario.
The scale of it for your purposes sounds like it would not be a great project.
Are you allowing Monarch to update the models to the dmod repository as you use them or are you using the utility to undertake that task?
If only using one of the methods it might be interesting to see if the other delivers a better result.
I suspect that the preview is, in effect, using the original xmod (if that is where you are starting from, and once you accept that and go for the full extraction it creates the dmod in the repository and attempts to repeat the lookup but "sees" a bad link and the lookup fails. Monarch is resilient enough to withstand that failure and continue. That might seem odd but I have used that resilience in a multi-pass process in the past to do consecutive dependent lookups using a single model.
Restarting and therefore resetting the cache in memory might be enough. In fact for a lookup on an Excel file I guess there is some possibility that the original lookup has the Excel file locked as "open" and so not available at that moment for the second data enquiry. I'm guessing there - but if so saving the model (likely automatic if no changes are made) and then reopening it might be enough to make it work?
That Excel based theory would not explain your "split on key" problem although the anomaly may have a similar basis if the xmod to dmod conversion is "as the model is used".
If you have an active support arrangement in place I would make use of it to see what advice is available - especially if you have a large number of models still to convert.