[SOLVED] Transaction number

[alfred07380]

Hi,

Since version 1.9.x, the operation number (ID) is a 16-digit integer.
On 1.8.x, this ID is 4 digits (for my file).
Let me explain:
When creating my first database, I imported a qif file from my old software (from year 2018 to year 2024).
My first transaction had ID 1 and so on. With each new transaction, the ID was increased by 1.
But since mmex 1.9.0, the transaction is 16 digits long, with no logical sequence to my existing transactions.
Is there a new ID calculation or a bug?

Thanks

[guangong]

this is to the new design of SUID, to enable distributed transaction ID and database in the future.

SUID starts with milliseconds, and it is still a logical sequence.

[alfred07380]

Ok. I understand. Thanks

[mvw6t]

I think you mean microseconds?

From my layman's perspective I would prefer if this was a new additional field labelled 'Timestamp' and we kept the old "ID" field issuing sequentially generated integer transaction numbers.

As I say I'm just a layman so I don't know if there are any particular reasons not to do the above.

[frankieorabona]

I’d like to share some feedback regarding the recent change in the progressive ID numbering system for transactions. I’ve noticed that in the new version, IDs no longer follow a simple sequential numerical order but instead use a 16-digit format.

I understand there might be a technical reason behind this decision, but I find this change unintuitive, especially for users accustomed to the previous method. It would be very helpful to have the option to choose between the old and new systems in the settings. Additionally, a notice or a popup explaining the reason for this change upon updating would be greatly appreciated.

Such changes, when introduced without prior notice or alternatives, can be frustrating for long-time users and might even discourage support for the project. I hope you’ll consider this feedback to improve the user experience.

Thank you for your work and for your attention.

[Georgen]

I also preferred the previous method.

[guangong]

just to be clear:
the 16-digit format still follows sequential numerical order

[dbolton]

The benefit for the longer ID is to avoid two transactions with the same ID. This can happen if you create a transaction on one device and a transaction on another device, then sync afterwards.

As I understand it, this is just the first step towards merging transactions between out-of-sync devices. The longer ID needs to be present on all versions (desktop, iOS, Android), before any further steps can be implemented.

If you are like me and find the new ID distracting, right-click on the ID column header and hide it.

[Pasol]

I think you mean microseconds?

I came across this thread while trying to understand the transaction ID. It turns out that it represents the number of microseconds (μs) that have elapsed since January 1st, 1970, up until the moment the transaction is validated. You might want to try this conversion tool (https://www.smartepochconverter.com/). Just enter the Transaction ID and it will give you the exact time when the transaction was validated.

This comes from my attempt to correctly import an exported CSV file from ‘Tous Comptes Faits’ (Innomatix). In this file, the main transaction has a date. The last field in the row indicates how many split transactions belong to it. The following rows contain those split transactions, all with a null date field. This means I’ll need to assign the same MMEX Transaction ID to both the main transaction and all its splits, since that’s how MMEX handles them. It shouldn’t be too complicated.

I know this thread is a year old, sorry .