This is the test connection made to decide on whether an import can be attempted. One problem we have is that error reporting on the php functions is non-existent. We are simply informed on whether it worked or failed. Not the reason for failure. Which means it is either the db name, user, password, host or table_prefix. Big help! We just do not know.

Having said that – looking at the code we can improve it a little (and I have already opened a ticket to get this done immediately) and at least make it possible to ascertain whether it is the connection or the attempted query. So that would narrow it down to either the database connection settings or – in this case, the table prefix/name.

If you would care to have the fixes so you can edit the copy you have I can paste them here for you to try out.

The other problem is that many forum software providers – and in my limited experience Invision are one of the worst at this – will change their database schema quite often which, of course, if we do not know about it can result in one of our import scripts becoming obsolete. Now I have not h4eard of Invision making any sweeping changes for at least 18 months or so so we should be OK but we always need to keep that in mind.

You know – I think we do NOT need to change any code now I have looked closer. So – the table prefix is the main contender. IS there one on your Invision tables?

and – let’s check. Is there a table called ‘members‘? And is the key or a column in that table simply named ‘id‘?

Hi, thanks for the reply.

It’s very strange, I am almost 99% sure the connection details are wrong because I recently used the exact details to make a remote connection.

I have just checked invision.php and I can see maybe the “id” is incorrect, because on my Invision DB we have “member_id”. I have however tried changing this but still get the same error.

$map[‘tables’]->users = true;
$map[‘users’]->table = ‘members’;
$map[‘users’]->select = ”;
$map[‘users’]->where = ”;
$map[‘users’]->ID = ‘id’;          <— should be “member_id” ?
$map[‘users’]->user_login = ‘name’;
$map[‘users’]->user_pass = ”;
$map[‘users’]->user_nicename = ‘members_display_name’;
$map[‘users’]->user_email = ’email’;
$map[‘users’]->user_url = ”;
$map[‘users’]->user_registered = ‘#timestamp:joined’;
$map[‘users’]->display_name = ‘members_display_name’;

Yes the table_prefix is set at:

http://puu.sh/3Zh3R.png

There is “members” and has “member_id”

http://puu.sh/3Zh54.png

well – at the point of failyre this is the query it is trying to run:

SELECT COUNT(id) as num FROM db-name.table-prefix_members;

So – if there is no ‘id’ column then change that to:

SELECT COUNT(member_id) as num FROM db-name.table-prefix_members;

Swap in the db name and table prefix and see what happens if you run it from a tool like phpMyAdmin…

Okay,

So tried both queries;

First one returned an error – http://puu.sh/3Zhq3.png

Second one returned this – http://puu.sh/3ZhsR.png

So it looks like “id” would be incorrect?

Agreed. But what that really means is that the scheme of your Invision database is clearly not the same as the one that was used to create the importer script.

So it would be worth checking all of the tables in the importer script just to make sure mappings are accurate. Pretty easy to do i think.

However – did you not already sau that changing id to member_id in the importer script did not change the success of the import attempt?

Hello,

Just tried again to change to “member_id” and it now successfully starts the import.

Thanks very much for your help, maybe you can roll this out for future…

Regards,

Curious. Is this a fairly recent Invision system?

Yellow Swordfish said
Curious. Is this a fairly recent Invision system?

Nope, this it’s been used for years, not exactly sure but probably 5-10 years?

okay, strange since we have numerous imports with it as is… but we will add a note to the importer in case someone else runs into this…