> Honestly trying to help
Of course, that's why we are all here, getting ideas

 > I think you are using the key to control the sort to control the
 > order...
I reasoned that as long as the key was sequential it would accomplish 
everything in 1 go.

I've got the whole thing built and functioning very well at this point, 
but if I have to do it again I can explore your idea of having secondary 
fields to control sorting.

Peter




On 9/23/2020 3:22 PM, Kevin Zawicki wrote:
> Honestly trying to help, the data scheme you have is the last thing I would
> do...
> 
> roughly speaking every entry should have a sequential key number (longInt)
> and then placement and sorting handled by other fields. I think you are using
> the key to control the sort to control the order...
> 
> 
> Maybe you have a sort field by day and control the insert and then resort
> 
> 
> 01/01/2020
> has five entries
> key
> 001  1 a
> 002  2 b
> 003  3 c
> 004  4 d
> 005  5 e
> 
> you need to add f at 1.5
> 
> I would change 2-5 to plus 1 and make new entry 2
> 
> end up with
> key
> 001  1 a
> 006  2 f
> 002  3 b
> 003  4 c
> 004  5 d
> 005  6 e
> 
> sorted on column 2, but f is key 006
> 
> 
> crude example
> 
> something like that, not doing the whole table, just days segment or hours
> or whatever.
> 
> or maybe a start timestamp
> 
> 
> 
> 
> 
> 
> Peter <peterspammenot@whiteknight.email> wrote:
>>> 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
>>>
>