Just in case anyone else uses or has used the

internalid

as an order sort for records created. We have filed the following defect on your behalf.  Defect 657699:  Document Defect > SuiteBuilder > Custom Record > Show IDs Field Level Help > Internal ID's generated are not guaranteed to be consecutive Alternate Solution*:*  After evaluation of the defect details, we’ve set the urgency level to U7. We are currently not planning to fix this defect - if no additional customer cases are added it will be closed after 24 months. If at any time additional customer cases are added and the urgency level is raised to U6 or higher, it will be considered for a future release. Read more about the urgency levels and targets in SuiteAnswers: https://netsuite.custhelp.com/app/answers/detail/a_id/74573

I can't access the defect details, but from the title it doesn't sound like a defect to me?

agreed, internalid is a very risky way to sort anything

I've used internalid all my years. Only until recently have I had issues with sorting this way. The defect is basically to update help and documentation to reflect this because it's not consistent.

this used to be a much bigger problem in ss1 when there was only nlapiSearchRecord

The recommendation is a search on created date. The problem I found with that is it's not indexed for the query. So searches are slow.

i used to sort by internal id, which failed when the internal id didnt always increase

In my case for my suiteapp, I've just created my own ID field based on created date parsed as an integer. This works better for me anyway because I need to be able to back up and restore the same order

I think internalids are increasing, just in the fact of parallel operations going on behind the scenes it may not seem so to an outside observer?

not what i saw, its was netsuite skipping by 100 internal id numbers, then returning to the skipped numbers later

ouch. later as in minutes later, or milliseconds later?

dont remember that much, it was ss1 days

years ago, we also did integrations based on internal ids and it seemed to work well.

Yah, I've always used the internal ID. Now I'm parsing to the millisecond for the custom id

Why not look at create date or last modified depending on need?

not entirely appropriate for paging purposes, those dates dont have enough precision to avoid duplicates

I found that date created is not indexed in the database. It causes my queries to become really slow. I also need a identifier for when I back up and restore the records.

what did the slow code look like