Build your own locate...


maybe get the desired value (194314.3)
then you know it is in the 194314 "series"

filter or query out to tcursor >194314 and less than 194315 to avoid a full
scan

then loop and test each value rounding to 1 place... 
or  string to string (using substr)

then sync the tcursor or locate on anther field if possible


you need to avoid rounding




Mark Bannister <markRemove@THISinjection-moldings.com> wrote:
>This is correct.  You should store this as alpha if you want this 
>functionality or break it into two fields.
>Changing to alpha would be the easiest I would think.
>
>
>On 12/1/2020 2:53 PM, Peter wrote:
>> I'll bet it is a rounding problem. Try viewing the number that Pdox is

>> searching.
>> 
>> I had a huge problem working with decimals, I ended having to create an

>> undefined field that awas formatted to 15 decimal places. I copy the 
>> number to that field and then read it, then everything behaves as expected.
>> 
>> Peter
>> 
>> On 12/1/2020 10:50 AM, Steve Levet wrote:
>>> I have a table with numeric tracking for orders. The Ordernum field is

>>> N and
>>> is the primary key. When orders are released which are not complete 
>>> any backordered
>>> items are copied to a new record and the Ordernum is incremented by 0.1.
>>> As an example I have an Ordernum of 194314.0, 194314.1, 194314.2, 
>>> 194314.3
>>> and 194314.4. When I click locate and enter the .0, .1 or .2 number 
>>> the record
>>> is found. However, any number above .2, eg 194314.3 or 194314.4 cannot
be
>>> found unless I select advanced pattern match. Any idea on why and how

>>> this
>>> can be corrected so that I can find the Ordernums above .2?
>>>
>>> Thanks.
>>>
>>> Steve
>>>
>
>-- 
>Mark Bannister
>256-509-2052
>