Recovery “?:0: attempt to index field ‘folder’ (a nil value)” error on Lightroom

Sometimes Lightroom start to tell you exoteric errors as the one in the title.
Those errors show when you press “Publish” or try to export some photos, and this become impossible.
I searched on the internet all the solutions and all says to delete the collections or the publish services with the problem, and start again.
A number of clues in all those articles made me suspect what the problem is, but only when I realized that a catalog in Lightroom is just a Sqlite database I finally solved the problem.
In this Tutorial I will show you a very crude way to recover from this errors. Anyway, it’s a very delicate operation and I’m not responsible of damages you can do following this procedure, but, if you follow me very carefully, you will have a backup copy.

Internal Error: ?:0: attempt to index field ‘folder’ (a nil value)

Ok, but what is that causes this error?
From my analysis, it’s some records inside the catalog that broke up. Maybe the photos on the hard disk are OK, but something inside Lightroom crash when it tries to open them.
Other symptoms are a very slow responsiveness when you change metadatas, or the impossibility to do this.

First steps

First, you’ll have to download the version for your operating system of  Sqlite. When you saved it, create a folder called as you want, I suggest Recovery, or so, and unpack the file inside the folder. You will need the file described as  “A command line shell etc…”.

This file will permit you to modify the contents of a database in Sqlite format.
Now make a copy of the Lightroom catalog inside this folder. This step is very important: you will delete by hand some records inside this file, so work only on a copy! Make another copy on another location: you will need it if you destroy everything. Now, load Lightroom double clicking on the copy of the catalog you made inside Recovery.
Now we will destroy it.

Destroy the Lightroom catalog

When you double clicked on the copy you made Lightroom starts on that copy of the catalog, so you will not destroy the original (but you made another copy, it isn’t?).
The error causing photos have a bad attitude: they can not be deleted. So, if we now remove all the folders of our catalog, those photos will remain even if no folder will be in the catalog.
You can remove the folder by right clicking them in the left panel choosing Remove from the contextual menu.

When you will have removed all the folders, some photos will still be there, maybe without preview if you copied only the catalog, maybe with the preview if you copied both files.
Anyway, these are not real photos, but only “ghosts”.
Now close Lightroom, we will now see what these photos are inside the catalog.

Open a MSDOS Prompt or a Terminal/Console if you’re using OSX. (In italian, this is Terminale. I don’t know if OSX uses Console or Terminal translation. Try it). Now use the DOS commands and move inside the folder Recovery. In my case:

cd Pictures
cd Librerie\ Lightroom
cd Per\ Articolo

This is the hardest part for the ones who don’t know the console. You have to know that cd means change directory and that you can see the content of the current directory using dir in Windows or ls in OSX.
Using those commands you’ll see the files inside the directory you are into, and so you can understand where you are and where to go to reach the Recovery directory you created before.
If you have problems here, give me a comment and I will try to guide you.

Enter the folder Recovery and launch:

sqlite3 "nome del catalogo"

In my case, I wrote:

sqlite3 "Catalago Generico 2012.lrcat"

You will see a new prompt, something like “sqlite>”. Now write:

select * from be_images;

semi-colon at the end. You will see a number of rows without intelligible sense, as follows (from my catalog):

350433|7ABA399F-479F-455C-ACA9-AA98474DEA28|2.0|2012-09-30T00:43:04.40|Profilato|371072766.987898|PX830 730 Artisan837 730 Epson Photo|soft proofing|350450.0|PSD|2464.0|4928.0||340654|AB|||||0.0|z||none|5.0|340655|0.0|6.0|371075837.092028
350526|F7514FB6-4FF4-4CBC-9467-8C68B521E9A3|2.0|2012-09-30T00:43:04.40|Profilato|371075818.53346|PX830 730 Artisan837 730 Epson Matte Paper-HW|soft proofing|350543.0|PSD|2464.0|4928.0||340654|AB|||||0.0|z||none|5.0|340655|1.0|7.0|371076009.897282
382854|FFECEEF4-0AF2-436B-8336-5998CC534A9F|0.662337662337662|2012-10-13T09:03:15.30|Profilato|372546416.896818|PX830 730 Artisan837 730 Epson Matte Paper-HW|soft proofing|382881.0|PSD|4928.0|3264.0||364969|AB|||||0.0|49.0||none|5.0|364970|1.0|10.0|373202808.889262

We now are in the hearth of Lightroom. Can you see the first number of every row? It’s the index of the image inside this table, and its name is id_local.
Now take all this numbers. Mine are  340654, 350433, 350467, 350526, 350562, 364969, 382854, 382897, 383029, 383119. These are the damaged photos inside my catalog, that prevent me to publish, export, and to live happy.

Now exit sqlite writing:


with the very important initial dot.

Things now are serious

Now you have to play with your original catalog. Copy it, or move it, inside Recovery, and open it using sqlite3, as you did before with the copied one.
Now, we will delete by hand the rows inside the Adobe_images table, so we can rid of the damaged photos.
Do it using:

delete * from Adobe_images where id_local in (…);

You have to write the semi-colon at the end, and substitute the three dots with the numbers you saw before.
Here you can see the screen from my computer with my numbers:

Exit sqlite.


Now copy this modified catalog from Recovery to the previous folder.

The end!

If you made everything ad I described it, now, when you open the catalog, you can start again to publish and export and modify metadatas and everything you want without problems and strange freezes.
If you made some error and everything in your catalog is trashed, you must pick up the second copy you made at the beginning of this article or from a backup. Just copy it on the modified one and start again.
Just a thing, remember that all the copies and all the modifications are made with Lightroom closed, so we can be sure that nothing is being modified while we work.

Note: this is not a clean system. Surely some reference to the damaged photos will remain into the database, but I never had problems.