Getting phone number from calculation

[RT]

Hi everyone.

 

i have a calculation that gives me the employee name and phone number.

 

Name_displayFull.c    & "-" & Employee_phone_cell

 

i am putting this calculation on an iPhone layout what i want to happen is when the user clicks on the calculation it calls the employee.

 

here is the script which works for the other  phone fields but not on this calculation field

Dial Phone

Filter ( EMP__Employee.tog::Employee_phone_cell ; "1234567890,+" )

 

anyone know how to get just the phone number from the calculation field.

 

Thanks

[Lee Smith]

I’m not sure of what the raw data looks like, but If I understand you correctly, just filter the numbers “0123456789” will only result in the numbers. For example 123-345-6780 will become 0123456789. 

 

Post a copy of the data as it is now for a better answer.

 

Lee

[comment]

I don't understand the relevance of this:

 

i have a calculation that gives me the employee name and phone number.

 

Name_displayFull.c    & "-" & Employee_phone_cell

 

If your script uses the original Employee_phone_cell field (as it well should), what difference does the calculation make?

[RT]

here is more of a insight.

 

i have customers layout on this layout i have a drop down from employees table which shows Active employees and there phone numbers. this gets stored in a field   Calculation - Team Leader- always evaluate storage is ALL  this shows up on the iPhone layout. (not a drop down)

what i need it to do is to call the number on the iPhone when i press the button so i am looking to drop the name part and just dial the last part of the calculation "the phone number"

 

the button set up at the moment for all my phone fields is currently.

Dial Phone

Filter ( EMP__Employee.tog::Employee_phone_cell ; "1234567890,+" )

or

Dial Phone

Filter ( CUS__Customer.tog::Customer_phoneDirect ; "1234567890,+" )

 

 

Thanks

[comment]

I am afraid I don't quite follow your description. I still think you should refer directly to the field where the original phone number is stored - not to the calculation field where it is combined with a name. Parsing the phone number out of the calculation makes no sense when the isolated number is available from the original field.

 

 

EDIT:

I also think (again, your description is not clear enough to be sure) that if you assign an employee as "team leader" for a customer, you should store their EmpID in the Customers table - and nothing else. Then you don't need ANY calculations; you can display and use data directly from the team leader's record in Employees.

 

 

For example,if you have a relationship:

 

Customers::TeamLeaderID = TeamLeader::EmpID

 

where TeamLeader is a TO of Employees, you can use the expression =

TeamLeader::Employee_phone_cell

to retrieve the team leader's cell phone from the context of Customers, and you can merge the fields TeamLeader::cFullName and TeamLeader::Employee_phone_cell on the layout of Customers without requiring a calculation field to combine them.

Edited November 13, 2013 by comment

[RT]

thanks for your time i will have some sleep and get back to you all tomorrow with a fresh brain cell

[Lee Smith]

Do you have separate fields for these fields?

First name

Last Name

Middle Name (initial)

Phone number

[RT]

Everything working great thank you for helping me. It still amazes me how you pros understand the problem from my brief question and give me an answer i can understand.

 

Thanks Again.

 

 

I am afraid I don't quite follow your description. I still think you should refer directly to the field where the original phone number is stored - not to the calculation field where it is combined with a name. Parsing the phone number out of the calculation makes no sense when the isolated number is available from the original field.

 

 

EDIT:

I also think (again, your description is not clear enough to be sure) that if you assign an employee as "team leader" for a customer, you should store their EmpID in the Customers table - and nothing else. Then you don't need ANY calculations; you can display and use data directly from the team leader's record in Employees.

 

 

For example,if you have a relationship:

 

Customers::TeamLeaderID = TeamLeader::EmpID

 

where TeamLeader is a TO of Employees, you can use the expression =

TeamLeader::Employee_phone_cell

to retrieve the team leader's cell phone from the context of Customers, and you can merge the fields TeamLeader::cFullName and TeamLeader::Employee_phone_cell on the layout of Customers without requiring a calculation field to combine them.

[Rick Whitelaw]

I must admit that I really don't understand this thread. Cell phone number should be a separate field, period. Concatenating a couple of fields then extracting the phone number, name, whatever is simply not advisable.

[Lee Smith]

It almost sounds like they are import this or scraping it for a web site?

[comment]

It still amazes me how you pros understand the problem from my brief question and give me an answer i can understand.

 

It amazes me even more when a cobweb of speculations and guesswork turns out to be helpful to someone...

[comment]

It almost sounds like they are import this or scraping it for a web site?

 

I shouldn't push my luck guessing even further, but I think they defined a value list using a calculation field = employee name & phone, and used it to populate a field in Customers. So they can see the selected employee's name and phone, but in the absence of a relationship they have no access to the corresponding record in Employees.

[RT]

That is correct if i look at the main customer layout i can see the name and number for quick reference, if i switch to the iPhone layout i see the same info but with an added bonus of touching the button to call the leader. the relationship has always been between customer and employee but the info was not available until i created a new TO very clever.

 

I shouldn't push my luck guessing even further, but I think they defined a value list using a calculation field = employee name & phone, and used it to populate a field in Customers. So they can see the selected employee's name and phone, but in the absence of a relationship they have no access to the corresponding record in Employees.