Are you looking at the same record when pair programming?

Are you looking at the same record? (a popular question when working with a user doing troubleshooting.)

Back in the day we only had serial numbers for primary keys. (They say it was a simpler time back then.)

These days we have both serial numbers and UUIDs (we like the text flavor of UUID).

If you are using UUIDs as your primary key AND you are troubleshooting with a user, how do you refer to the record?

In most system we add zz_RecordID_sCN and zz_RecordID_uCN fields.
In systems that use long hard to read UUIDs...we can use RecordID to identify a record.

How do you address making sure you are both looking at the same record while doing troubleshooting?

In systems with no replication requirement and where imported records get system-generated IDs, it is serial numbers. Makes troubleshooting with users way easier. Otherwise UUID and serial is used, as you described.

Some tables will still have a serial number, or they are grouped by a serial number, so that is a starting point because it's usually simple to find and to use.

A lot of the problem goes away when we use screen sharing tools like teamViewer.

If something prevents us from using screensharing and we are really having trouble I have asked for a screen shot to be emailed. That has proved a lifesaver a couple of times.

3 Likes

Our back end is UUID but the end user very rarely ever see the back end and instead we have a ID filed that is human readable. But there are times this dose not work and then we use TeamViewer's free option Blizz.com. it lets you share the screen and click to point something out but not control the other computer. I am also testing Guilded.gg hoping it will help with communication and screen sharing.

we still have serial numbers. Might be that there are uuid's as well

We often support 'foreign' solutions, solutions created by sombody else. Sooner or later, one person is calling and telling us that there are records deleted by the system, magically. If there is a sn-field, we check for missing 'id's'... Often in those applications, not every one can delete - so some clever ones will overwrite an entry...

We are processing about 15'000 (more, every month) xml invoices. There are some billers who send in the same invoice 2 or more times for unknown reson - but they do. We got kind of uuid's in that system, but checking (sometimes) visually for doubles are much easier with the relative short invoice-no...
(sometimes, they do a 'new send', then the uuid will be changed, sometimes they send the very same file another time)

We’re much the same as many here. If we can get away with it, serial numbers every time due to data tracing and debugging. If mobile is involved, then we opt for UUIDs.

1 Like

We use a Karbon-like approach ( with many elements pulled directly from Karbon ) and have a log of every db transaction that happens. The scripts pick up a lot of metadata from the design functions ( and soon more from the Execute Data API step ).

We also have Advanced tools enabled on every internal machine. Makes for easy live debugging. A button to capture a screenshot and bunch of other metadata can also be very useful.

1 Like