Codebook Windows

Has anyone else noticed that the field entries in an entry in Codebook for Windows when created by an Android client are in a different order?

I have “Email Address” and “Password” as 2 fields.

When synced they come across as “Password” and “Email Address” - They have the correct content just in the wrong order.

RBB

Hey @rubberbandboy

Thanks for using Codebook and posting to the discussion forum, although I’m sorry to hear about the trouble. Would you please try running Integrity Check on each device and see if it reports and errors? Then relaunch Codebook on each device and see if the ordering is consistent.

Integrity Check is at this location within Codebook on each device:

Windows: File menu > Integrity Check
Android: Settings > Integrity Check

Let me know the results. Thanks!

I don’t know if this is necessarily a Windows-Android issue. A similar issue has been plaguing me for some time, and I use no Android devices. What I found is that, over time, Codebook seems to rearrange the order of the fields in the display. What was entered as Username, password, URL, Note end up in usually reverse order on display. It seemed happening to older entires, but I hadn’t really been paying attention to it - just edit, drag back to the correct order, save and sync. I have not identified a common thread among those that it re-arranges, but suspect it may have to do with database changes implemented on various updates over the years. As an aside, the database in question was initially ported to iOS from PalmOS (that’s how long I’ve been a Zetetic user… I think I started using S.T.R.I.P. shortly after it came out for Palm.), and, though they imported correctly back in the days of yore, most of the reversed entries could be old enough (to my memory, anyway), to have been from that era.

I use Apple iOS (Currently Codebook 4.2.1 - 908, 2 devices) and Windows 10 (Codebook 4.2.2.0, 4 devices) equipment exclusively, and sync through Google Drive. Vigilant on keeping the OSes up to date as well, though one Windows device and one iPhone are corporate devices, and subject to their update roll-out schedule. Currently, the corporate windows machine is lacking the 1809/KB4558998 update (not for want of trying: it fails to install, and I cannot troubleshoot due to their policies); otherwise, all equipment is up to date. Integrity checks generally turn up only incorrect sort indexes.

More of a nuisance than anything else - I’ve never identified any missing fields.

Hey @pbabcock

Thank you for using Codebook, being a longtime user, and posting to the discussion forum detailing the issue you’re running into.

There are some valid cases where the ordering of your fields are ambiguous. I’ll outline one of these such situations below:

  1. You have an entry with no fields which was previously synced between multiple devices (let’s call it “TestEntry”)
  2. Add a field on device 1 and give it a value “Device1”, this will place the field at the first index (first in the list) of the entry on device 1.
  3. Add another field on device 2 and give it a value of “Device2”, this will place the field at the first index (first in the list) on the entry on device 2.
  4. Sync the two devices. The result is that each device now has two fields on the entry “TestEntry” but each field is in there first index spot. When displaying the fields, Codebook displays them ordered by index, but because each field has the first index the order in which they’re displayed could be ambiguous.

To resolve this issue, typically running an Integrity Check will “repair” these incorrect indexes on each device.

From your description, it sounds like you’ve run Integrity Check which resulted in the message that “Incorrect Indexes were repaired”. Are you still experiencing the incorrect field ordering after this? If so, are you adding fields on different devices to the same entry as outlined in the example above?

No, this isn’t a case of update collisions. Most of the entries have never been updated since having been entered, and the revised order (literally: reversed) is consistent between all devices. There are also no, nor have there ever been any, entries with no fields that I’m aware of - particularly any that are now populated entries. (I had to go create one just now to see if Codebook would even allow one to be saved! It does.) Again, more of a nuisance, so I’m not expecting the cavalry to save me. I just saw rubberbandboy’s post and thought my experience might be pertinent.

If I notice a recently-created record flipping like this, I will follow up. It seems to occur in the “ether” between uses though, so I doubt I could intentionally reproduce it or tell you what manner of computational demon I may have conjured to cause it.

@pbabcock

Thanks for the further details and clarification.

There are also no, nor have there ever been any, entries with no fields that I’m aware of

Apologies if my description was misleading, I was just using that as a simple example. The valid case of reproduction isn’t necessarily predicated on having an entry with no fields to start.

I just saw rubberbandboy’s post and thought my experience might be pertinent.

Absolutely. Thank you for sharing it. We appreciate receiving feedback and definitely want to know when more users are experiencing and identical issue.

If I notice a recently-created record flipping like this, I will follow up.

Great. Thank you. If you’re able to reproduce it we’d definitely like to look into it further to get it fixed up. We’ll also continue to keep an eye out on our end during testing and usage.