FYI in case anyone else thought this was a vBulletin bug
 

Reply just in from vBulletin support, and are those folks getting fast on the answers :)

Some one was asking my advice as to whether or not this was a possible bug in vBulletin before purchasing. Thank fully l can say it isn't and just posting it in case other's have read the message on the net and were wondering.

HTH.

It can break custom hacks that expect specific usernames or userids; also, for example, the tables userfield, post, thread, privatemessage, mailmessage, mailfilter, mailfolder, mailab, etc.

edit: stock vB doesn't have a problem (except when just deleting a row from the user table), but hacked vBs, which many people, including myself run, don't always integrate with vB's user deletion system. So you're fine if you want to use stock vB :)

Custom usernames or userids, gee some people need to go back to college and learn about not hard coding information into software. Thank fully the 60 or so hacks we use, don't cause this problem, but then again we have some mighty fine php coders on the team (this doesn't include me, l'm technically lame).

So, do you expect people to create a database field for every tiny hack they make? I don't think so.

And, for the record, I can't go back to college, considering I am still in high school.

Maybe you're misinterpreting what I meant; I mean that some rows reference nonexistant userids in some tables (other than user, of course). As such, strange things could happen when those userids are further queried to get username, styleid, etc.

I'm not sure what you are on about here. We have added exactly two table fields in the course of development. Hard coding what should be variable data is considered extremely bad coding practise in any language. Do some reading as to the reasoning behind it :) I would suggest some of Fabian Pascal's stuff, who's one of those relational db experts that keep us all informed of normalisation, though l am at a bit of a head scratching stage with seventh normal form. Don't know, if some one else could explain it that would be cool.

Hey when you graduate go to college young man. Keg parties and co-eds and all that....

Should add thread was only started as a response to a question and through Jelsoft's answer to it.

The offending statement should perhaps be changed to reflect the true situation rather than being able to be misconstrued as meaning there is a problem in the underlying vBulletin software.

As I've said, stock vBulletin doesn't have a problem.

Let me put the analogy a different way; in my webmail hack, there's a mailmessage table with a column, among others, of userid. This column obviously stores the userid of whom the message belongs.

Now if the user was deleted via vB's user deletion system, the user/userfield rows would be deleted and all posts set to guests (not sure how PMs are handled). However, in my hack, the rows with that user's userid would still remain. The results could be unpredicable, from either just junk taking up space in the database, queries failing when trying to join data between tables, or some other bizarre problem.

Virtually every type of hack like my webmail hack--i.e., a hack that stores data per user--is affected by this problem. :)

If all of the user's data, that includes any PMs, posts, etc that they may have, is deleted via database queries, there should not be any problems.

Filburt, it's as simple as running a simple MySQL query to delete rows with that user's userID. Any admin that knows their way around VB, PHP, and mySQL should have no problems whatsoever. :)

I know. But, as I'm reiterating for the third time, most hacks that are in the data-per-user genre do not integrate with vB's user removal system and therefore are not cleaned up when a user is deleted.

Also edit your profile immediately to change your website to something appropriate.

In real life practice, normalization often does not result in the best performance. Trade offs have to be made when you do not have infinite cpu processing time.

Er that would be a simple hack to the software dude, any competent PHP coder could do it for you, if you require help with it. :)

Freddie, l code with IBM databases which have something called virtual fields which gets around the trade offs, not sure of the MySQL equivalent. Any database that is not at least at 2nd normal form runs the risk of redundant data, and conflicting data for the same value. Generally l go to third normal form, but not much beyond.

All of this is off track as the board in question has in fact removed several people without this being a problem. Just had confirmation of that fact from a member at another technical site.

So one is left bemused by this statement, clearly an Admin is concerned that once one person gets removed a lot of other people will want to be removed.

Of interest asked the folks over at bbAdmins their views on removing member accounts from their boards, response so far is 100% they do so. Equally none of the vBulletin users report any problems with doing this, and as some of these guys run huge boards would image they may include some of the hacks which poise a problem apparently.

My reasons for not removing users are my own, and this technical issue is one of the many I've outlined. Please keep this thread related to the technical aspects.

Actually this did start in chat, some one has clearly moved it.

Do you need help with your PHP code to get your hack working correctly with the delete members option. Our tech admin Chris is a PHP guru and would be more than pleased to help, as he has fixed a similar problem for us. Just offering.

Yes, I moved it because it was related to vBulletin.

I have professional programming experience with PHP myself; not to sound offensive but you don't have to make me sound like an idiot...However, as you do not know how I have WDF configured internally (it is way more complex than it looks), it would not be worth my effort to peruse the code to fix any problems, let alone publish those fixes to the dozens of free and for sale hacks I've produced.

Well, it seems both unbelieveable and highly unlikely that the technical issues raised bythe board in question, would in fact be true.

I find it hard to believe that someone with professed PHP and MySQL skills at such a high level would have any difficulty with the removal of member accounts. Given that the technical reasons are not impossible to get around (far from it in fact, given that the board has deleted several member accounts in the past without apparent problem)

If that is not the case, then that leads one to only several conclusions....

1. The Admin choses not to remove the accounts because it would truly reflect the state of said board, and not reflect well on him.

2. The Admin has a perculiar and persistent grudge against the individual members and won't remove them out of spite.

3. The Admin has a very poor understanding of his legal obligation to remove people from lists whereby email is sent to members and individuals...upon request.

4. The Admin does not realise he is in breach of Federal US misrepresentation laws, whereby, he is misrepresenting people as being members of his forum, when they are not, have never been members of his current forum....And then bans them when they come online to request removal???


Any way you look at it, it is completely unprofessional and irresponsible behaviour from supposed "professionals" (as the staff members of the board in question claim to be) if any member of my staff acted that way they would be removed immediately from staff and from the forums.

Does MySQL not have cascading updates? (I'm an MSSQL man myself).

If it did then it would be a trivial task to make sure data consistency was secured.

As it is, surely it is only a few minutes job to set up an SQL script that would delete all references to a particular ID from a database.

Sorry, but as this is in no way related to vBulletin in general but one specific site, thread closed.

(Martin, please post your question in a separate thread :))