OK, Kura

I looked into this and this is actually a bug in the database backup.

The away date is NULL by design but when you download the SQL file, it turns it into NOT NULL.

You will need to open your .sql file for the user table, and find:

And change it to (the highlighted stuff from above should be deleted):

After that, you will have no problems.

I will report this bug on vBulletin.com

Cheers,

Bira

The hack is nice but my files are just to hacked up to install anymore without the hack installations that include line numbers. The installer doesn't show line numbers. No more installer hacks. Maybe someone could add line numbering to the installer proggie.


The hack is very nice though Bira. ;)

Great, thanks, I will try this soon (watching a movie, when it's a break I will do this) and let you know what the outcome is. :)

Thank you :)

Hooper line numbers will not help you.

If code x was on line 100, then after you hacked your script it will be on line 108, then how would it help if I gave you line #100 in the installer?

Line numbers work ONLY on a very clean and non-hacked script.

[QUOTE]Originally posted by bira
Hooper line numbers will not help you.

If code x was on line 100, then after you hacked your script it will be on line 108, then how would it help if I gave you line #100 in the installer?

Line numbers work ONLY on a very clean and non-hacked script.

Hooper, you're awfully demanding and picky, ya know that?

Line numbers are not at all useful with hacks. Hacks that say "find **example line** and ADD ABOVE that **hacked code line**" and the like are much better in this aspect, for no matter what line this will be at, you can simply find it and add to it the necessary changes.

Also, when a new version of vbulletin is released which adds about 60-80 lines above this line, the line numbers would be WAY off, but if you just search for the strings it doesn't matter.

[QUOTE]Originally posted by Hooper
I just will not install no more hacks that don't display line numbers.

W3rd bira :)

Btw, it worked this time, I removed the three NOT NULL's and the dump installed sweetly over my empty install.


Only strange thing, however, was the fact (nothing to do with this hack btw) that... well, this:

I had two vbulletins running on my comp, the Couch and the Couch v.2. I only use the first one for installing hacks in preparation of my new sites and everything. The second one is only installed to simulate when I switch hosts and will have to insert a dumpfile into an empty (fresh) install.

Now, the dump-inserting worked, everything worked smoothly and all. But then I made a thread on the Couch v.2, and went to a site (also on my HD) that runs a query that lists all the threads from one specific forum. It listed the new thread. At first I was "Yay it works!" but then I realised, it was a Whole Different Database! But it STILL took the new thread!

So I checked the other Couch, the original one, and the new thread had appeared there as well.

So when i made a thread on ONE forum, it magically copied itself to the database of the OTHER forum. That database has a different name, a different mySQL user and a different mySQL password.

Any idea why on earth this happened??

are you sure you didn't overwrite config.php?

If you are running two databases, you gotta make sure you have two different config.php. That's the gateway to the db :)

You're very correct.

I *initially* had a different config.php of course, with the new username and db-name and everything. But then I realised that I took the files from the vB221 zip, and thus was missing out on several files (install_awayusers.php being one of them) and I copied all the files from the first board, to the directory of the second board. And I forgot to exclude the config.php file for the DB-settings. Heh..

Thanks for pointing that out to me. :)