Fixed problem importing vB4 albums

We look at your VB database to see if you had the option enabled to store attachments as files or whether it used database storage.

If the setting is configured to use files, then you should be prompted to confirm the path. However...

I have just looked at the code and a blank VB4 database I have and I suspect there could be a bug here, so I have a couple of questions:
  1. Are your attachments stored on the file system or are they in the database?
  2. Can you run the following query on your VB database and let me know the result:
SELECT value
FROM setting
WHERE varname = 'attachpath'
If you use a database prefix, you will need to add that to the table name above, e.g. if your table prefix is vb_, the above query would read "FROM vb_setting".
The attachments are stored in the file system.

Running your query it says the files are in "/path/attachments"

However, my resorted attachments are in "/path/sorted-attachments". The importer never prompted me to ask for the correct path.

So how to fix? Thanks!
As I thought; that's a bug then.

Simplest solution for now is to rename the attachments folder from /path/sorted-attachments to /path/attachments :)
The user IDs of the users who uploaded images and created albums.

If albums are being imported then this is working correctly.

What did you mean about the attachments being sorted in "an odd way" and how did you fix that?
What's the result of this query on your VB database?
SELECT value
FROM setting
WHERE varname = 'attachfile'
That's not even a valid value for that setting as far as I know.

I believe that setting should either be 0 if files are served from the database, 1 if the files are served from the old style structure from VB3 or 2 if the files are served from the newer structure e.g. 1/4/3.

With that in mind, I was expecting that query to return 2.

If VB is no longer in use, it should be safe to change it to the value we expect:

UPDATE setting
SET value = '2'
WHERE varname = 'attachfile'
Yeah we're still live on vB4, but I'm using a copy on a dev server to work out these migration kinks, so it's safe to change.

So I'll restore the database to before this failed import and try again.
Excellent; incidentally I have added a fix to the next release for an actual bug which may prevent the attachment path being edited. Thanks.
Top Bottom