> You could maybe use a longInt as the key first field, then maybe a 
non > key other longint to control the sort or placemen with a secondary
 > index?

Hmm, not sure that would work. The problem is that I have to be able to 
make alterations after the fact. For instance these records are entered
1
2
3
4

Afterwards an additional record needs to be inserted between 1 & 2. The 
way I see it, I have to use decimals.

 > or I have has systems where an alpha field(s) with segments, 1.1.1
 > 1.2.1

Hmm, I never fully thought out the string idea "1.1.1". I just did a 
quick test and it does sort as needed. Sitting here, I don't know if 
that would offer any savings though because I still have to do all same 
lengthy process to increment/decrement the decimal part. However, it 
would save all the grief that pdox presents with the number type.

Thanks for the feedback.




On 9/22/2020 9:45 PM, Kevin Zawicki wrote:
> Not knowing the context...
> You could maybe use a longInt as the key first field, then maybe a non key
> other longint to control the sort or placemen with a secondary index?
> 
> 
> c
> etc.
> 
> It seems to me that you have to alter the key field on the records around
> the you are inserting?
> 
> 
> Peter <peterspammenot@whiteknight.email> wrote:
>> I cannot use rounded figures.
>>
>> I use these numbers for unique ID ("EntryID") in the first field of my
>> table. I need to be able to insert new records in between sequentially
>> numbered records:
>> e.g.
>> 1
>> 2
>> 3
>> 4
>> 5
>>
>> May need to become
>> 1
>> 1.1
>> 2
>> 3
>> 4
>> 5
>>
>> Further it may need to become
>> 1
>> 1.01
>> 1.02
>> 1.03
>> 1.1
>> 2
>> 3
>> 4
>> 5
>>
>> Getting crazy
>> 1
>> 1.01
>> 1.001
>> 1.002
>> 1.02
>> 1.03
>> 1.1
>> 2
>> 3
>> 4
>> 5
>>
>>
>> In reality the adjustments will never get past 3 decimal places, but
>> then Gates/Allen never thought anyone would need more than 1mb of memory.
>>
>> So I cannot set the format to "x" decimal places because the places is
>> limitless - well 15 digits actually
>>
>> a number such as 1.103555555555566 is unusable
>>
>> I solved the problem by separating a number into 2 strings
>> left of decimal
>> right of decimal
>>
>> There is an awful lot of screwing around to increment/decrement the
>> decimal part but it basically involves establishing numbers by putting
>> them into an undefined field formatted as 15 decimals
>> "UfldDec = entryid" (N) in the first fld of the tbl
>> and then retrieving as a string
>> "StrDec = UfldDec"
>>
>> Once I have the decimal formatted as a string it cannot be reverted to a
> 
>> number for calclations because then the answer is back to 15 digits, so
> 
>> the calculations have to be done with strings. Yeesh!
>>
>>
>>
>> On 9/19/2020 8:38 AM, Steven Green wrote:
>>> numbers are interesting.. do you want the round of the sums, or the sum
> 
>>> of a bunch of rounds.. by setting a "default" number of places, that's
> 
>>> what you're doing
>>>
>>>
>>> -- 
>>>
>>> Steven Green
>>> Myrtle Beach, South Carolina, USA
>>>
>>> http://www.OasisTradingPost.com
>>>
>>> Collectibles and Memorabilia
>>> Vintage Lego Sets and Parts
>>> - and Paradox support, too
>>> "Peter"  wrote in message news:5f651f65$1@pnews.thedbcommunity.com...
>>>
>>> I sure do hate calculating with decimals in Pdox.
>>>
>>> I found that I needed at the beginning of my code
>>> "formatSetNumberDefault("Dec15")"
>>> to be able to get all the decimals I need; the number of decimals is
>>> completely fluid.
>>>
>>> At the end of the code I have
>>> "formatSetNumberDefault("Fixed")"
>>>
>>> Is there a way to get the default number format? Thank you.
>>>
>>>
>>> Peter
>