Database Error 1002

968x601 Database

Database Error 1002

This issue was resolved in Roastmaster 7.0.2

With iOS 7, Apple ushered in a lot of changes, both in the look of the OS as well as much of its underlying functionality. One of the more impactful changes for Roastmaster was a big shift in how Core Data operates with SQL databases like Roastmaster’s. As with any shift in technology, it has not been without its share of bumps in the road.

It has surfaced since iOS 7 that in two uncommon scenarios, Roastmaster may display “Error opening database: 1002 – Could not perform compatibility check” when either launching the app and opening the main database, or manually opening any other database.

Why Does This Happen?

If you encounter this error due to either of the following two situations, do not fear – your data is not gone, Core Data is simply refusing to open it.

In BOTH of these cases, I can easily and quickly reset the offending “flag” in the database file, and send it back to you in its original operational state. This error can present due to one of two situations:

You have recently experienced an unexpected shutdown of your iOS device. This can be due to a hard reset of the device (such as in a hang, freeze or kernel panic), or due to the device shutting down on its own (such a in a low battery situation, or other iOS or hardware malfunction).

If an iOS device experiences a core OS freeze, and a hard reset is performed, or the OS unexpectedly reboots for another reason, iOS may fail to reset the “busy” flag of the database files, causing Core Data to reject the database the next time you attempt to open it because it thinks the files are already in use.

I can easily reset the busy flag by simply opening it in an external SQLite editor, exporting it via Roastmaster and sending right back to you.

You have just restored or setup an iOS device from an iCloud or iTunes backup

During the backup process, when iCloud or iTunes encounter a Roastmaster database file (.sqlite), it notices its two supporting cache files (.wal and .shm) and coalesces all three into a single, portable .sqlite file, in a process similar to what Roastmaster performs when you export a database. The single resulting .sqlite file(s) are backed up to iTunes or iCloud and stored in the device backup. This all happens transparently in the backup process.

It appears that in the coalescing process, iTunes and iCloud fail to reset the journal mode on the database(s) from WAL mode (3 files) to DELETE mode (1 file). During the restore, it restores an intact .sqlite file, but since the journal mode is erroneously left as WAL, iOS expects the 2 supporting files. When it does not find them, it refuses to open the database.

I can easily recreate the extraneous cache files by simply opening it in an external SQLite editor, exporting it via Roastmaster and sending right back to you.

How Do I Get My Data Back?

Regardless of which of these situations has presented itself, your data can be easily retrieved.

If You Have an Exported Backup (or can make one from another device)

If you have an external backup that is up to date, or are able to export an up-to-date file from another Roastmaster installation, this is the easiest way. Just import the resulting sqlite backup file into Roastmaster, and open that database by tapping the logo on the home screen, tapping the database button and opening it manually.

If You Do Not Have a Backup

You will need to send your database folder to me and I will “reset” the database. All that is required on my end to simply open the database in an external SQL editor. This will either A) reset the “busy” flag if it was left marked as “in use” after an unexpected reboot or B) reset (what I believe) to be an erroneous journal mode not properly set during the coalesce phase of the iTunes/iCloud backup.

In most cases I can do this immediately and return the database file back to you for easy import, and you will be up and running in no time.

Since Roastmaster actually opens a database to prep it for export, you will not be able to export the database from the app. You will need to use iTunes file sharing to copy the databases folder to your desktop by following these steps:

  1. Tether the device to iTunes
  2. In the “File Sharing” pane of the “Apps” tab, select Roastmaster
  3. In the “Roastmaster Documents” pane, find the “Databases” folder and copy the folder to your desktop
  4. ZIP that folder and email it to support@rainfroginc.com

I will return a single database file that can be easily imported from Dropbox or email or copied to your Roastmaster documents folder via iTunes file sharing, then choosing “Import from documents” from Roastmaster’s home screen.

When Will This Be Fixed?

Unfortunately, it does not appear that I can do anything to fix either of these bugs until the actual causes are revealed. The bugs lie in either iCloud, iTunes or iOS itself – it’s unclear at the moment. I’ve filed two separate bug reports with Apple outlining the problem, and how to reproduce it.

If you’ve found this page after encountering this error, PLEASE let me know – even if you don’t need my help in resetting your database. The more users I can report having this issue, the higher priority Apple is likely to assign to getting it fixed for good.

  1. Erik Grammer
    Erik GrammerFeb 05, 2014

    Hi Danny,
    I was looking for the screen casts and came across this post. I did not have 1002 errors until I started setting up the data probes in late January. I have now had 5 or 6. As far as I can tell, it has only happened when there is a freeze up during the probe setup. (The screen freezes and no input is possible for as little as 10 seconds and as long as “I get impatient and reset the iPad). Either way, when I exit the preferences and go to the main screen I get the database loading error. I just import a backup from Dropbox and overwrite as I backup after every roast. Best of luck with Apple.
    Erik

    • Danny Hall
      Danny HallFeb 05, 2014

      Sorry for your troubles. The frustrating thing is that absolutely nothing at all is wrong with the database. In situations like yours, it appears that iOS erroneously leaves the “busy” flag turned on. Consequently, iOS won’t let Roastmaster open it because it thinks it’s in use.

      If you encounter a situation where you don’t have a backup, just send me the zipped database folder. I simply open it in a SQLite editor, which resets the flag, then send it back to you. Takes about 10 seconds for me.

      I’ve been working with Apple’s bug reporting since last month, trying to get to the bottom of these. Finally opened a support ticket earlier this morning. Hopefully I’ll have a way around this in place soon.

      I’m concerned, though, that you experienced lags or freezes in the probe details screens. The good thing is that, once they’re defined, you don’t really have a need to visit them again. But, I’ve never seen had any freezes or lags with Phidgets there.

      Given the 1002 error, don’t test it. But if you find something stands in the way of your workflow until this is sorted out, please don’t hesitate to let me know.

      Danny

      • Erik Grammer
        Erik GrammerFeb 05, 2014

        Really not a big deal here. I’m very on top of backing things up after every session – always to dropbox and often as a local backup as well. Not sure what caused the probe screen lags… could have been other things going on with the ipad, might have had the phidgets application open on the laptop without realizing it, could have been related to trying to assign the device to the wrong port. If I do ever find myself without a current backup and have the error again I will send you the database (and hopefully a more cogent description of what caused the problem).
        Thanks!
        Erik

        • Danny Hall
          Danny HallFeb 06, 2014

          Ahh – OK. The Phidgets SDK does its best to prevent different devices from connecting to the same Phidget at the same time. Sometimes it works, but behavior can be erratic and undefined. Multiple connections from one device (such as your setup) are fine, though.

          Thanks for letting me know – on both counts. I keep reports like this in mind while coding and put in “checks” for these situations where possible.

Leave a Reply to Erik Grammer Click here to cancel reply.