Text parsing

[eyeguy]

Hi everyone

I have the need to parse some data but am not sure how to do it.

I would appreciate some advice.

 

I have a text field with data  e.g.  /Volumes/Documents/jsl/Referrals/EP15849245201392441jsl.pdf

I would like to grab this data and place it in a variable but strip out the "/Volumes" part

 

Can anyone suggest how I can do this?

[eos]

Let (
[
myField = myTable::myTextfield ;
thePos = Position ( myField ; "/" ; 1 ; 2 )
] ;
Middle ( myField ; thePos ; 5000 ) // calculate the length, or just use a number guaranteed to be large enough
)

[eyeguy]

Holy *******!

Worked like a charm

 

Many many thank you's

[LaRetta]

Middle ( myField ; thePos ; 5000 ) // calculate the length, or just use a number guaranteed to be large enough

 

It is always better to indicate the precise amount instead of a random number such as 5000 or sometimes I see folks post 99999 etc ... 

 

It is a waste of evaluations forevermore every time that calc runs in that solution for as long as it exists ... when the value is already known by the developer and could have been entered properly to begin with.  Be precise in all you do and go for optimum in every calculation and script and your solution will run faster.  It is even more critical in this era of iOS and WAN.

 

So the 5000 should be replaced with:  Length ( myField ) - thePos + 1

 

Since volumes is always at the start, you might also use:  Replace ( myField ; 1 ; 8 ; "" )

[bruceR]

And that will never ever make any difference.

 

Understanding the concept of significance is also important.

[LaRetta]

And I listen to two of the greatest Developers who have ever lived (Ray Cologon and Michael Horak) and they both have said same thing repeatedly over the years.  I take my advice from them.  What you say makes little difference to me.  You and I constantly disagree.  You think convolution is fine.  I do not.

 

In addition, by entering (what they think) would be the largest number that the text would ever be, they run risk of misjudging and having it fail later when unexpected.  And it is NOT the concept which should be presented on a forum because those newer in the business will assume it is fine and it is NOT FINE and it is NOT RIGHT.

Edited September 1, 2013 by LaRetta

[bruceR]

Yes. The oops I did not guess a big enough number problem is a real problem and using length() as you and Ray and Comment mention is the best solution.

[LaRetta]

And that will never ever make any difference.

 

Understanding the concept of significance is also important.

 

I could not agree with you more, Bruce so I am going to help you understand.  

 

Simply, SPEED IS ALSO AFFECTED, as I said before, when using static larger number than needed.   Please see zip attached (fm7 and fmp12 formats).  Tests were ran 10 times each, then the average was taken and results are ... drum roll ...

 

99999 44 seconds

Length() 39 seconds

 

5 SECONDS!!!  Actually the difference was 8 seconds but I'm giving the benefit.  Imagine if you believed it was okay to over-specify in 3 formulae in that looping script.  Now cut the time in half to be optimistic and sit back and count 7 seconds and pretend you are a user waiting for FileMaker.  Forevermore when that script runs ... waiting an extra 7 seconds because the Developer did not take the added TWO seconds to be precise with the calc.  It's not like it is difficult to decide what should go there!!  It is a simple Length ( myField ) after all.  It should really be Length ( myField ) - thePos + 1 but I wanted it consistent for the tests.  I imagine it would be even faster by another few seconds if the variable were set with the proper value or even if a different calc were used but I wanted a tight comparison.

 

Further, if you believe this is safe practice (specifying a too-large number) then you will continue to use it throughout your solution and it will slow it down even further when used in calculations, conditional formats, scripts and over WAN ... and why?  Simply because the developer did not take the added effort of calculating a specific answer one time.  That is so wasteful.

 

So yes, Bruce, every evaluation ( including a Set Variable[] within a script ) takes a toll and we Developers should take the time because it saves many minutes/hours over the lifetime of the solution.  There are ALWAYS ways of improving speed, none of us knows them all; in fact, I realised that we could have the best of both worlds ... … in this instance, since the Length() is static throughout, we can instead set a variable with its value before the loop thus being precise but also static and knocking off another 1.5 seconds. 

 

Added:  Tests were almost identical if ran in version 12 ( at least on this Mac 10.8.4 ).  I could have used Get ( UTCmSecs ) in 12 but I wanted to keep the tests consistent.  bTW, there are no / in any of the text ... but that does not matter.  The test is comparing against evaluation time only.

Optimise_overSpecify.zip

Edited September 2, 2013 by LaRetta

[eos]

[…] It is a simple Length ( myField ) after all. […]

 

No, it isn't. 

 

Middle

Format 

Middle(text;start;numberOfCharacters)

Purpose 

Extracts the numberOfCharacters from text, starting at the character position specified by start.

[LaRetta]

LOL, I DO know how to use the Middle() function but thanks anyway, Oliver!!  Yes, I had used Length() by itself to match your calc more closely for the test.  It would be Length ( theField ) - thePost + 1.

 

But that was not my point at all ... it was using a WAYYY larger-than-needed number than even the field length.  THAT was why I left it using the FULL field length for the test.  Sorry if it was confusing.  

 

Point is ... you DID know what needed to be placed there and it WASN'T difficult at all.  As said, I wouldn't have used Middle() for this anyway.  I would have used Replace() which, it turns out, would have been slower than Length ( theField ) and faster than 99999.  :-)

Edited September 2, 2013 by LaRetta

[bruceR]

LaRetta: thank you for proving exactly my point.

 

The point being: understanding what is significant.

 

And tracing scripts.

 

If you look carefully at your file you will see that the buttons in your file were mislabeled.

 

Your "Using Length" button is attached to the variable script.

 

The times, on my machine WITH CORRECTED BUTTONS are:

 

205 seconds for 99999

218 second for length

191 second for variable

 

I only ran one run each.

I quit FileMaker between runs.

I ran the tests in reverse order (variable; length; 99999)

This was using the fp7 file only.

Modified file attached.

 

Bruce

Optimise101.fp7.zip

[bruceR]

Result for FM12 version of corrected file, on an SSD equipped Mini:

 

 

62 seconds for 99999

66 seconds for length

51 seconds for variable

[LaRetta]

Eyeguy, we are not trying to hijack your thread - my apology.  But this discussion may affect the speed of your solution which is why I spoke up to begin with.  Whether Bruce or Oliver or I agree or not is irrelevant ... the best answer is what we all are after.  :-)

 

BTW, the third script is completely bogus since it is outside of the loop and will only use the first record's value.  That's what I get for mixing work and play.