dotNetBB > vB 3.6.8 p2

[mjp]

Going from dotNetBB v2.42EC SP2 > vB 3.6.8 p2 but getting a weird failure on the first step using impex.

So I start with module 001:

Get database information This module will check the tables in the database as well as the connection.

And I keep getting failures where it expects to find donNetBB that is says are missing -- like:

AdminActions NOT found.
AdminCategory NOT found.

Etc.

The tables are there though. So I tested "Get database information" by putting intentionally incorrect values in the connection string of the ImpExConfig.php file, but I get the same results.

So I guess "NOT found" is impex's way of saying it can't connect to the target db. Which is odd, because it makes connection troubleshooting difficult.

I can connect to the target db via command line from the machine that vB is running on, so I am at a loss.

Has anyone done a successful dotNetBB > vB impex?

[Jerry]

And I keep getting failures where it expects to find donNetBB that is says are missing -- like:

AdminActions NOT found.
AdminCategory NOT found.

Etc.

The tables are there though. So I tested "Get database information" by putting intentionally incorrect values in the connection string of the ImpExConfig.php file, but I get the same results.

So I guess "NOT found" is impex's way of saying it can't connect to the target db. Which is odd, because it makes connection troubleshooting difficult.

I can connect to the target db via command line from the machine that vB is running on, so I am at a loss.

No, if it couldn't connect to the database it would say that, what it said there is that it can't find the two tables, and as there are a lot more you aren't quoting the entire page, if all of the tables aren't found, then it will take a guess at what your table prefix is at the bottom of the page, which is what is likely wrong.

Has anyone done a successful dotNetBB > vB impex?

Of course, or the module wouldn't exist.

[mjp]

No, if it couldn't connect to the database it would say that, what it said there is that it can't find the two tables, and as there are a lot more you aren't quoting the entire page, if all of the tables aren't found, then it will take a guess at what your table prefix is at the bottom of the page, which is what is likely wrong.

I don't doubt what you're saying, but as I said, as a test I put an invalid login/password into the config file and "Get database information" still ran, saying it couldn't find the tables. I can't get a database connection error out of it - and I tried - because I wanted to rule that out.

You were also right about the table prefixes, but I fixed that and the script still doesn't find the tables, which is why I suspect a connection issue. I am running this on my desktop machine as a proof of concept (because I'm trying to get my company to switch from the horrible dotNetBB).

It is php running on Windows, and I have the connection to SQL manager open on the same desktop that vB is running on. So I can see the dotNetBB tables there. but impex cannot. So I'm just wondering inf there's something I'm missing. I will include the whole page below.

Of course, or the module wouldn't exist.

I know, that was a poorly worded request for assistance for anyone who has gone through the same thing.


---

ImpEx build version : 1.87

Database cleanup & restart ||| Online manual
Using includes/config.php for target config.

Altering tables

ImpEx will now Alter the tables in the vB database to include import id numbers.
This is needed during the import process for maintaining refrences between the tables during an import.If you have large tables (i.e. lots of posts) this can take some time. They will also be left after the import if you need to link back to the origional vB userid.

moderator - importmoderatorid OK
usergroup - importusergroupid OK
ranks - importrankid OK
poll - importpollid OK
forum - importforumid OK
forum - importcategoryid OK
user - importuserid OK
style - importstyleid OK
thread - importthreadid OK
post - importthreadid OK
thread - importforumid OK
smilie - importsmilieid OK
pmtext - importpmid OK
avatar - importavatarid OK
customavatar - importcustomavatarid OK
customprofilepic - importcustomprofilepicid OK
post - importpostid OK
attachment - importattachmentid OK
pm - importpmid OK
usernote - importusernoteid OK
phrase - importphraseid OK
subscription - importsubscriptionid OK
subscriptionlog - importsubscriptionlogid OK
SMB_ActiveVisiting NOT found.
SMB_AdminActions NOT found.
SMB_AdminCategory NOT found.
SMB_AdminMenuAccess NOT found.
SMB_AdminMenuTitles NOT found.
SMB_AvatarGallery NOT found.
SMB_CalendarDetail NOT found.
SMB_CalendarEvent NOT found.
SMB_EmailBan NOT found.
SMB_EmailMessages NOT found.
SMB_EmailNotify NOT found.
SMB_Emoticons NOT found.
SMB_FileAttachments NOT found.
SMB_FilterWords NOT found.
SMB_ForumCategories NOT found.
SMB_Forums NOT found.
SMB_ForumSubscribe NOT found.
SMB_GroupMembers NOT found.
SMB_Groups NOT found.
SMB_Ignored NOT found.
SMB_ImageThumbs NOT found.
SMB_IPBan NOT found.
SMB_MailConfirm NOT found.
SMB_Messages NOT found.
SMB_MessagesRead NOT found.
SMB_Moderators NOT found.
SMB_ModMailer NOT found.
SMB_PollQs NOT found.
SMB_PollVs NOT found.
SMB_PrivateAccess NOT found.
SMB_PrivateMessage NOT found.
SMB_Profiles NOT found.
SMB_SearchIndexPost NOT found.
SMB_SearchIndexTitle NOT found.
SMB_SearchWords NOT found.
SMB_Stats NOT found.
SMB_Titles NOT found.
SMB_UploadAvatars NOT found.
SMB_UserExperience NOT found.

vBulletin® v3.6.8, Copyright ©2000-2008, Jelsoft Enterprises Ltd.

[Jerry]

Do you have any other PHP applications connected to the database ?

Is the dotnet connection using ODBC?

[mjp]

Do you have any other PHP applications connected to the database ?

No.

Is the dotnet connection using ODBC?

You mean the dotNetBB forum itself? No, I believe it's OleDB. Most .net applications use OleDB in lieu of ODBC these days...

[mjp]

Okay, I tried some simple database connections via php from the same directory the impex files are in, and using mssql_connect() fails:


$myServer = "111.111.111.111";
$myUser = "username";
$myPass = "password";
$myDB = "database";

//connection to the database
$dbhandle = mssql_connect($myServer, $myUser, $myPass)
or die("Couldn't connect to SQL Server on $myServer");

//select a database to work with
$selected = mssql_select_db($myDB, $dbhandle)
or die("Couldn't open database $myDB");

[fails]


But a connection string with ADODB does connect:


$myServer = "111.111.111.111";
$myUser = "username";
$myPass = "password";
$myDB = "database";

//create an instance of the ADO connection object
$conn = new COM ("ADODB.Connection")
or die("Cannot start ADO");

//define connection string, specify database driver
$connStr = "PROVIDER=SQLOLEDB;SERVER=".$myServer.";UID=".$myUser.";PWD=".$myPass.";DATABASE=".$my DB;
$conn->open($connStr); //Open the connection to the database

[connects]


Is that any help?

[Irksome]

I am having an identical problem, clean import from dotnetbb 2.42EC SP3.

[Irksome]

I've been troubleshooting this all day and have found a solution that works for my situation.

I added the a key named DSQUERY with string value DBNETLIB to my PHP server's registry at :

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo]

this prevents the server from trying to use Named Pipes to connect to the SQL server, forcing it to use TCP/IP

Appears to be a PHP problem.

Irksome

[Jerry]

Good find

I'll have to research that and stick it in the manual.

[mjp]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo] ?

My path in registry stopped at "Client," so I don't know if you added "ConnectTo" or it's just one of the million irritating variations of Windows.

Anyway, I got it to work as well, though I used a more slash and burn method.

Since I wasn't using MS SQL on the Windows machine I am importing data to (the target DB is on another server), I just deleted the MS SQL server from the importing machine completely, dropped a current version of ntwdblib.dll into /apache/bin and /php and now the import is running.

So I am not sure if I was running into the same problem as Irksome, but nuking the MS SQL server worked for me. I realize that may not be a reasonable option in some (most?) import scenarios, but I'm just doing a proof-of-concept, so I'll probably be back with other problems when I convince them to make the actual switch.

[Irksome]

MS SQL isn't running on the same server in my case either, but the registry key Client\ConnectTo was already present.

I guess you just add the ConnectTo key if it is not already present, it contained nothing else.

I did the import - and made the site live overnight as it was long overdue - there are some problems with imported html code, missing attachments and truncated threads, but otherwise :-) all is well. It was the user data I was most concerned with importing.