I have been working on this recently and tried the links in this and other questions, but in the end settled for using Chrome.  It was easier, quicker and less moving parts as Chrome was already on the servers. 

/// "C:\Program Files\Google\Chrome\Application\chrome.exe" --headless --disable-gpu --print-to-pdf="E:\Data\Spooler\2022-07\DN560241_14a.pdf" "E:\Data\Spooler\2022-07\DN560241_14.htm"

strExePath=..getChrome()  // This function just handles the fact some machines put chrome in program files, others in program files (x86)
s1=$ZF(-100,"/LOGCMD /NOQUOTE /STDOUT+=e:\logs\H2POUT.log /STDERR+=e:\logs\H2Perr.log",strExePath,"--headless --disable-gpu --print-to-pdf-no-header --print-to-pdf="""_strPDFPath_""" """_strHTMLPath_"""") // For some weird reason this flags as an error when it completes, no idea why, but its not valid.
//w "S1: "_s1,!!
//I $$$ISERR(s1) Q $SYSTEM.Status.GetErrorText(s1)
"0*Error Occurred" }


Thanks Timo

The codebase of this system is over 30 years old. They came up with suffixing as their solution and its used in a lot of places. As much as I can see prefixing as a better solution overall, there is no way to make that happen. So I'm stuck battling with what I've got. I've a few ideas now on where / how to approach a new search function for this class of data set, but no shining silver bullet. 

Hi Stuart

Thanks for the ideas. I think the key is to force the comparison to a string search, because the numeric search gets a bit hairy, but I'll have to go away and play with a few ideas and the real data and see what comes out in the wash. 

Hi David 

You're right, there are no numeric values in the global, all values are suffixed with a space. The issue occurs when the actual value of the search string is numeric, (i.e. the prefix you're searching for has no alpha characters in, regardless of the state of the matching value in the global).

The code I had worked fine for any non numeric search strings but not with fully numeric ones. The logical solution would seem to be to add the space onto the search string to convert it to a string and then run the search, however that doesn't return the data expected. 

I think I need to take all the suggestions above and go away and play with another version of the search function, possibly combining a numeric and string search function to get the complete matching data set. 

Thanks for the suggestions. 

Thanks Robert

I still don't see how that addresses my question, but I understand what you're suggesting now. 
You're giving it the last value of the search, and you're also still looping through the entire global.  The first I don't have unless I calculate it and the second is what I'm trying to avoid.

I think my solution may lie in forcing the numeric search prefix into a string and going from there.  I'll have to go back and play. As is the oft the case, writing it all down to explain it has clarified a few things for me :)

Thanks Robert. 

I understand that the value is being treated as numeric.  I couldn't get my head around how "8009 " matches "800999 " because the space should invalidate the match, but I've just realised that that space is a lower ascii value than the numerics and alpha characters. 

I don't understand your suggestion about using $QSUBSCRIPT, could you possibly provide a line of code to show how you're suggesting it would give me a range end. 

Have you tried just creating a new folder with the dat file in, and then going to add a new db and pointing it at the same folder that you added the dat file? It should then pick up and use the existing dat file for the new db. 

I'm loving the examples, however I'm a little confused by the last running total.  Either I'm misunderstanding what it's trying to do or its not doing what I think it should.

The ACC_EXPENSES column seems to be only taking the first value for a given date and adding it into the running total instead of all the values for a given date. In the below image the date 1/1/23 has 3 rows, 300, 230 & 330, which total 860 as seen in the TOTAL_EXPENSES column. 

The ACC_EXPENSES value for 1/2/23 should be the sum of 1/1/23, (860) and the sum of 1/2/23, (880), but instead its showing 730, which is the sum of the 2 rows I've highlighted above. 

Just thought, I had a lot more success easily accessing CACHE ODBC tables via WinSQL. 
The Lite version is free, and you'd just need that and the ODBC drivers and you'd have a simple way to access the data.