I've sent 2 emails in the past week that never showed up (and aren't in the archives). Testing to see if this gets through.
Message received via Gmail.
On Fri, May 18, 2018 at 8:37 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
I've sent 2 emails in the past week that never showed up (and aren't in the archives). Testing to see if this gets through.
On 2018-05-18 08:37, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
Well, other post still not making it, so I'll add the simple request here since this went through:
FieldValue1 = '123-456-7890'
I want to scan for records where the field contains something OTHER than digits 0-9 and a dash. I recall it was some magic with one of the TRANS that compared to itself and thus if the result was not equal, it meant the field contained invalid characters outside your desired set.
tia, --Mike
m.x="123-456-7890"
CHRTRAN(m.x, "0123456789-", "") will leave any invalid characters behind
Frank.
Frank Cazabon
On 18/05/2018 08:52 AM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
On 2018-05-18 08:37, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
Well, other post still not making it, so I'll add the simple request here since this went through:
FieldValue1 = '123-456-7890'
I want to scan for records where the field contains something OTHER than digits 0-9 and a dash. I recall it was some magic with one of the TRANS that compared to itself and thus if the result was not equal, it meant the field contained invalid characters outside your desired set.
tia, --Mike
[excessive quoting removed by server]
I don't know if this would interest anyone but me, this thread got to me to thinking about a method I wrote years ago for my library class to clean text up and remove a default set of characters, but I can also pass a custom set of characters to be removed. It's called CLEANTEXT and the heart of it is the CHRTRAN command that Frank suggested.
His command noted it would leave behind invalid characters. So as a mental exercise, I created a new method called CLEANTEXT_NUMBER and it will use Frank's command to identify the invalid characters and then remove those invalid characters from the original string to leave you with only the good characters you want to leave behind without needing to know the invalid characters you want removed. In this new method, you just need to know what you want to keep. For example if you don't pass a value for the pcRequestedChars, it will assume you want just the digits to remain. But if you pass a special list of requested characters, it will return just those characters if they exist in the original string.
PARAMETERS pcStringToClean, pcRequestedChars LOCAL leRetVal, lcValidChars, lcRemoveChars
If pcount() = 1
lcValidChars = "0123456789"
else
lcValidChars = pcRequestedChars
endif
lcRemoveChars = CHRTRAN(m.pcStringToClean, m. lcValidChars, "")
leRetVal = CHRTRAN(m.pcStringToClean, m.lcRemoveChars, "")
RETURN leRetVal
Stupid stuff I know, but a nice quick mental exercise! Thanks, Frank!
Paul H. Tarver
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Frank Cazabon Sent: Friday, May 18, 2018 8:01 AM To: profoxtech@leafe.com Subject: Re: String help (was Re: [ADMIN] Testing post to ProFox)
m.x="123-456-7890"
CHRTRAN(m.x, "0123456789-", "") will leave any invalid characters behind
Frank.
Frank Cazabon
On 18/05/2018 08:52 AM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
On 2018-05-18 08:37, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
Well, other post still not making it, so I'll add the simple request here since this went through:
FieldValue1 = '123-456-7890'
I want to scan for records where the field contains something OTHER than digits 0-9 and a dash. I recall it was some magic with one of the TRANS that compared to itself and thus if the result was not equal, it meant the field contained invalid characters outside your desired set.
tia, --Mike
[excessive quoting removed by server]
On Fri, May 18, 2018 at 8:55 AM, Kurt Wendt vrfx@optonline.net wrote:
PGRpdiBkaXI9J2F1dG8nPlBpbmchPC9kaXY+
What Kurt said. Happy Friday!
On 05/18/18 9:25 AM, Ted Roche wrote:
On Fri, May 18, 2018 at 8:55 AM, Kurt Wendt vrfx@optonline.net wrote:
PGRpdiBkaXI9J2F1dG8nPlBpbmchPC9kaXY+
Understood, comrade. <whispers> "The frog in the pond utters an azure cry."
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Ha ha Ted - funny! What I actually wrote was... Ping
On 5/18/2018 9:25 AM, Ted Roche wrote:
On Fri, May 18, 2018 at 8:55 AM, Kurt Wendt vrfx@optonline.net wrote:
PGRpdiBkaXI9J2F1dG8nPlBpbmchPC9kaXY+
What Kurt said. Happy Friday!
On May 18, 2018, at 7:37 AM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
I've sent 2 emails in the past week that never showed up (and aren't in the archives). Testing to see if this gets through.
Nothing in the spam filter, so I'm not sure why they didn't get through.
-- Ed Leafe
--- StripMime Report -- processed MIME parts --- multipart/signed text/plain (text body -- kept) application/pgp-signature ---
On 2018-05-18 13:14, Ed Leafe wrote:
On May 18, 2018, at 7:37 AM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
I've sent 2 emails in the past week that never showed up (and aren't in the archives). Testing to see if this gets through.
Nothing in the spam filter, so I'm not sure why they didn't get through.
Weird. 3 different attempts never reached the list.
Yes
On May 18, 2018 8:37 AM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
I've sent 2 emails in the past week that never showed up (and aren't in the archives). Testing to see if this gets through.
[excessive quoting removed by server]
On Fri, May 18, 2018 at 8:37 AM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
I've sent 2 emails in the past week that never showed up (and aren't in the archives). Testing to see if this gets through.
No, sorry Mike, still nothing ;)
Have a good weekend!
-
Ed Leafe -
Frank Cazabon -
Jim Brotz -
Kurt at VR-FX -
Kurt Wendt
-
Man-wai Chang -
mbsoftwaresolutions＠mbsoftwaresolutions.com -
Paul H. Tarver -
Ted Roche -
Vince Teachout