Need help with Foxpro command

[bluechart]

My client gave me a datafile with email addresses connected the the email name, for example.
joe@xxx.comJoe Boxer (joe@xxx.com)

I want to replace a new empty field with everything up to and including the '.' and the three following chrs.
ie joe@xxx._-_

subs(fieldname,'.',3)

If you can help, please do so, I am in a jam.

Steve

 

[JRB-Bldr]

You might try something like this...

mcEmailString = "joe@xxx.comJoe Boxer"
mnDotLocation = AT(".", mcEmailString)
mnDotPlus3 = (mnDotLocation + 3)
mcEmailAddr = LEFT(mcEmailString,mnDotPlus3)

Good Luck,


JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com

 

[mmerlinn]

One thing you need to watch out for is email addresses that have only two characters after the dot. They are not common, but they do exist. I know because my email address ends in ".fm" and there are others.

If you are positive that all of yours end in ".xxx", then the above solution should work for you.

Otherwise you might want to change this line:

[tt]
mnDotPlus3 = (mnDotLocation + 3)
[/tt]

to:

[tt]
mnFirstLetter = ASC(SUBSTR(mcEmailString, mnDotLocation + 3))
mnDotPlus3 = mnDotLocation + IIF(BETWEEN(mnFirstLetter, 97, 122), 3, 2)
[/tt]

This checks the THIRD character after the dot. If it is between 'a' & 'z' (LOWER case) inclusive, you have a three-character extension, otherwise a two-character extension is assumed. This assumes that ALL extensions are LOWER case and that ALL first names begin with UPPER case.

This is untested, so may need a bit of tweeking.





mmerlinn

"Political correctness is the BADGE of a COWARD!"

 

[bluechart]

Everyone has been very helpfull, but I am lost....

I was looking for a command line like

replace newfield with substr(fieldname,'.')+3

I do not know what mc, mn, are, or how to phrase this command line.

Thank you for any suggestions. I am using foxv 2.5

 

[JRB-Bldr]

You gave us no indication where the original email string was coming from (a memory variable or a table field??) nor where the result was to go into (another memory variable or another table field???).

And you neglected to let us know that you wanted to do this as a one-line command rather than using a record-by-record processing loop such as SCAN/ENDSCAN.

And mmerlin's comments above are accurate should you have email addresses such as Something@xxx.tv or other similar addresses. If so the "+3" approach will not work.

I would have hoped that somewhere back in high school Algebra you were shown how to replace portions of an equation with other pre-defined equivalencies.

AB = "ABC"
CD = "1234"
XYZ = AB + "-" + CD
by using equivalency replacements you can see that the above XYZ is the same as
XYZ = "ABC" + "-" + "1234"

You could have used that principle on what was suggested above to end up with something like the following:

REPLACE NewField WITH LEFT(EmailField, (AT(".", EmailField) + 3))

BTW: mc, mn, and other variable prefixes are merely part of variable naming standards used to help the code reader understand what type of value the variable is intended to contain.

Admittedly, most people no longer use the "m" part of it, but I still cling to it to definitively indicate to others that I am referencing a Memory variable instead of a table field or other object. I guess that for me it is a hard-to let-go-of hold-over from the old "m." days.

So when you see a
mcSomething or a cSomething it implies that it is a Memory variable containing a String value.
mnSomething or a nSomething ==> memory variable - Numeric
mdSomething or a dSomething ==> memory variable - Date

Good Luck,


JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com

 

[mmerlinn]

[ ]

I CUT and PASTED my code into JRB's last posted code and came up with this.

All I did was to cut & paste the code, then drop the 'mc' prefixes from the resulting command to match the variable 'EmailString' that JRB used.

Really quite simple, as JRB stated, with no additional typing involved. This means that I did not accidently introduce any errors by mistyping something or other.

[tt]
REPLACE NewField WITH LEFT(EmailString,AT(".", EmailString) + IIF(BETWEEN(ASC(SUBSTR(EmailString, AT(".", EmailString) + 3)), 97, 122), 3, 2))
[/tt]

Trying to debug this resulting monstrosity is almost impossible when in this form. It is much better to do as we did above as the original code is soooo much easier to debug. Once the bugs are gone, then cutting and pasting all those lines into a single line usually results in code that runs properly without further problems.




mmerlinn

"Political correctness is the BADGE of a COWARD!"

 

[bluechart]

Okay, I have it!

Thank you all for your help!

Steve

 

[JRB-Bldr]

mmerlinn - the only issue that I might take with your approach is that we cannot be sure that BlueChart has provided us with the whole 'story'.

When he uses as an example joe@xxx.comJoe Boxer for his initial email address string, it indeed changes from LowerCase to UpperCase where he wants to 'break' the string apart.

And, assuming that was indeed a standard that applied to ALL of his beginning strings, then indeed your addition would work well.

But with all of the information that he neglected to tell us, we cannot be sure that using the LowerCase to UpperCase change is a reliable method to determine where the 'real' email address ends.

And, Yes indeed, debugging a single complex command string like that would be a real challenge - especially if there is limited understanding of the individual commands contained within.

BlueChart - I am glad we could help, but keep in mind that the primary reason we offer suggestions in the Tek-Tips forum is generally NOT to do the work FOR people. Instead it is so that we can offer suggestions which can assist people with their "opportunity to learn".

Many of us make a living getting paid to do the work FOR people.

You might also want to take this opportunity and spend a little time getting familiar with Foxpro's Help file.

Good Luck,


JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com

 

[mmerlinn]

[ ]
jrbblr

He most certainly did not post the whole story in the original post.

All I basically did was to validate your post based on what he DID state, then offer some additional code based on my own experience. And you are absolutely correct - what I added ONLY works provided all of his fields are in the same format as the example he posted. Notice the caveat about capitalization and standardization that I wrote in my first post.

Also, I normally don't use prefixes like you do. However, to be consistent so as not to confuse the issue, I coded my reply using the same standards that you originally used.

BlueChart

I am glad we could help. However, as JRB stated, if you are going to be coding in FoxPro, or any other language for that matter, you really should be spending some time learning the basic concepts of the language in question. It really helps us at those times that you need help if you are able to speak the same 'language' we do - FoxPro in this case.

I notice you are using FP2.5. When this version was originally released for use the manufacturer included about 5 inches of books with the disks. If you have them available, you will find that they contain most of what you need to know for normal FoxPro programming. If they are not available, watch eBay. Periodically (like last week for example) you can pick up a full set of manuals with original disks, sometimes new-in-box, for $25 to $50 per set. If you don't have the manuals, that would probably be the best place you could spend your money - very cheap education to say the least.


mmerlinn

"Political correctness is the BADGE of a COWARD!"

 

[JRB-Bldr]

Mike - "use of M instead of m. doesn't tell FoxPro you're referencing a variable"

You are correct. I mentioned that it helps to inform the reader of the code the nature of the variable.

And you are also correct in that if both a memory variable AND a table field had the same name such as:
mcThisValue -- Memory Variable
MyTable.mcThisValue -- Table Field
then the code would indeed likely get 'confused'.

That is why, even back in the old days of non-Visual Foxpro, I only used the "m" variable prefix on Memory Variables and not on table field names so I would have something like:
mcThisValue -- Memory Variable
MyTable.cThisValue -- Table Field (no leading "m")

In that way there would never be BOTH beginning with "mc" and yet the reader could still identify that the values were intended to be Character Strings.

Plus back then using the "m." to precede and identify memory variables was reported to create code which executed slower than code which just referenced the memory variable with the distinct name by itself (I never tested this myself). Consequently I avoided it when possible and used just names (albeit distinct names) without the "m."

Good Luck,


JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com