Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Matrix rate
Message
From
28/06/1999 21:47:32
 
 
To
28/06/1999 21:28:21
Dovi Gilberd
Dovtware Consulting Inc
Miami, Florida, United States
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Title:
Miscellaneous
Thread ID:
00233562
Message ID:
00235043
Views:
28
>ed.....! thank tou so much..im working on it o see if it works..looks like it will. taht is very kind of you helping me out..
>i know i got a long way to go....
>the function gives me an error that says lead dialednr character "3"not suported
>would it be because there are calls that were not completed meaing they habged up before the called went throgh and it only recorder 1,2,3,4, or 5 cumbers..?
>
>

From looking at your code, it appeared that depending on what the first character of the field view1.dialednr, the number of characters to use as the prefix value for the seek was 4 characters for a lead character "0", 6 characters for a lead character "1", or 3 characters if the lead character was "#". Your code didn't show what to do if the lead character was anything but one of those three values, so in the DO CASE...ENDCASE, I added an ASSERT to the OTHERWISE part of the statement that showed you what the lead character was (match the message up to what you see in the ASSERT statement). This was what I meant by defensive coding - the first character was not one of those you'd planned for, so that The OTHERWISE part of the DO CASE...ENDCASE was triggered.

If this was what you intended (I based it on the code you initially gave back to Barbara, that presumably did what you wanted done), you had a value in data that had not been planned for, and this caught it. If this wasn't what you intended, write out what you want to do as a simple statement. I'd noticed that Barbara had recommended previously that you normalize your table structure (good, solid advice from my point of view, since it gives better flexibility in the long run and reduces the complexity of the code) so that you didn't have to spin through the fields trying to find the right column to use, and I'd assumed that this logic fragment had come out of that redesign.

>
>
>
>>Hi barbara..how are you today...im still doing this rate thing
>>>im using this function that returns to the grid the correct rate name..
>>>what comes next....?please
>>>
>>
>>I hate to say this, but your code makes no sense. Why do you pass in any value at all to getRate(); you reference neither of the parameters at any time anywhere in the code shown. You also needlessly complicate the code with the EVAL(). Finally, you never select a table in the code, so that unless you've pre-selected the target table, your SEEK will never work. try the following, code; I think it does what you want and demonstrates some simple techniques for trapping errors, preserving the state of VFP, and defensive coding in general:
>>
>>
FUNCTION GetRate
>>LOCAL lcInAlias, lcSeekValue, lcCheckDigit, lcAssertSetting, llFoundPrefix, lnResult
>>lcInAlias = ALIAS() && save the currently selected work area
>>lcAssertSetting = SET('ASSERTS') && and the SET ASSERTS mode
>>lcSeekValue = NULL  &&default seek value to NULL
>>lnResult = NULL  &&default result to NULL
>>llFoundPrefix = .F. &&And by default the seek failed
>>SET ASSERTS ON  && enable asserts
>>IF ! USED('long_distance')
>>   *  if the lookup table isn't in use already in this datasession, open it
>>   USE long_distance IN 0 SHARED && make sure the table is in use
>>ENDIF
>>SELECT long_distance  && Select the lookup table before trying to find in it
>>SET ORDER TO <i>whatever tag is correct</i>  && in the right sort order
>>*
>>*  I use a local variable so that the LEFT() function is only called once,
>>*  and the code becomes a tad clearer in the DO CASE
>>*
>>lcCheckDigit = LEFT(view1.dialednr,1)
>>*  Check how many characters to use for lookup based on first character
>>DO CASE
>>CASE lcCheckDigit = '1'
>>   lcSeekValue = LEFT(view1.dialednr,4)
>>CASE lcCheckDigit = '0'
>>   lcSeekValue = LEFT(view1.dialednr,6)
>>CASE lcCheckDigit = '#'
>>   lcSeekValue = LEFT(view1.dialednr,3)
>>OTHERWISE
>>   *  Oops - the dialednr isn't in the form we expected - use an ASSERT
>>   *  to let us know an error occurred while developing, to let us go
>>   *  into the debugger when the error occurs.  ASSERT gives us a message
>>   *  telling us what we think went wrong as a part of the statement
>>   ASSERT .F. MESSAGE 'Lead dialednr character "' + lcCheckDigit + '" not supported!'
>>ENDCASE
>>IF ! ISNULL(lcSeekValue)
>>   *  the dialednr started with a valid character, so try to find the prefix
>>   *  we grabbed from our rate table
>>   llFoundPrefix = SEEK(lcSeekValue)
>>ENDIF
>>IF llFoundPrefix
>>   *  found it - save the rate we found!
>>   lnResult = long_distance.rate
>>ELSE
>>   *  oops - not in our lookup table - use ASSERT to let me know
>>   *  what went wrong
>>   ASSERT ! ISNULL(lcSeekValue) MESSAGE 'Cound not find number prefix "' + lcSeekValue +'" in long_distance table'
>>ENDIF
>>*  Restore the initially-selected work area and the ASSERT setting
>>IF ! EMPTY(lcInAlias)
>>   SELECT lcInAlias
>>ELSE
>>   SELECT 0
>>ENDIF
>>SET ASSERTS &lcAssertSetting
>>RETURN lnResult
>>
>>When debugging, this will give you some meaningful error messages, letting you go intot he debugger at your option when errors occur. If a rate is found, it is returned from the function; if for any reason, no rate is found, it returns a NULL, which you can check with ISNULL() on return (a default rate could be substituted instead, or a predefined, otherwise illegal value that you could test for.) This makes sure tht the current selected work area is reset after you return from the function, and preserves the SET ASSERTS setting present before you called the function. When run under the runtime, the ASSERT statements do not degrade performance or pop up debug dialogs, so you don't have to pull them out when you move to production.
>>
>>There's a lot of defensive coding above, and the SEEK logic could be written to avoid the SELECT process, but the code should be a bit easier to understand the way I wrote it here, and demonstrates some useful techniques for preserving the stte of VFP inside a function.
>>>
>>>FUNCTION getrate()
>>> PARAMETERS Result,codigo
>>> cRateField="long_distance.rate"
>>> IF LEFT(view1.dialednr,1)="0"
>>> SEEK LEFT(view1.dialednr,6)
>>> endif
>>> IF LEFT(view1.dialednr,1)="1"
>>> SEEK LEFT(view1.dialednr,4)
>>> endif
>>> IF LEFT(view1.dialednr,1)='#'
>>> SEEK LEFT(view1.dialednr,3)
>>> endif
>>>
>>>
>>>
>>> RETURN EVAL(cRateField)
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform