Quote:Yes it can be shortened, but there should be some sort of delimiter in the source string. Can you post what the source string looks like?
I'm not sure what you're asking. The field being tested is a billing code field (customer number). If any of those 14 codes are entered a message box pops up with special instructions for the user.
You're probably right about just leaving it as is in Q&A and then changing it in Sesame.
Quote:Are you trying to shorten code to get past the Q&A code size limitation?
Somewhat. I have purchased John Dow's marvelous DTFDOCTR and DTFSPECS utilities and they have been very helpful in cleaning up my Q&A programming. My program's sizes do have rather high percentages, but I haven't hit the limit yet.
My main problem is the programming structure. Erika has taught me a lot about how a program should
look in order to make sense of it, things that I did not know when I first wrote the Q&A programming. The first time I tried an (experimental) translation of my Workorder and Invoice databases I was dismayed by the way the programming looked in Sesame. You know how with Q&A you only have that little F6 box to work with - everything ran together. It was totally baffling, especially since Sesame changed all my well-documented field numbers into field names. John's utilities allowed me to extract all my programming into files I can edit with a text editor and then import back into Q&A. Once that's done I will translate again, and when the field numbers change to field names I expect things will look a lot better in Sesame. And then at
that point I can begin shredding the heck out of it.
I still have yet to take the advanced Sesame programming classes, so in the meantime I'm reworking my Q&A programming, getting a refresher of how these databases work "under the hood", and making lots of notes for future tweaks.
This one particular piece of code is not very important. I was just wondering it the @INSTR function could be used to test against multiple-character strings.
Thanks for your help.