TYPO3 Core

Any news on this issue? Does it still exist?
In which TYPO3 release did you experience this behaviour?

Oliver, thank's for your reply.

My TYPO3 Version was 4.2 but I can't remember any more details and as described I had this with earlier versions too.
I think It could have been to do with (wrong?) utf-8 setup so that some files are wrong or never interpreted - but I'm not sure at all about that. Referring utf-8 Franz Holzinger once remarked that danish signs have been responsable for some missbehavior (don't know which kind) - but we could solve it without changing the core. Another case with missinterpretation of sourcecode are commented '?>' signs. When files are changed and transferred between unix and windows linebrakes sometimes are removed - that's a reason for this and some other possible "faults".
As I said: I'm really not sure because I also can't remember but I think the fault could have to do with something like that.

In the moment it's not actual for me - I'm working with several versions and for myself I'm able to get the system running always.
Regrettable this point does not give any information to the public neither to any - if any - faults in the core.
But I hope the hint about transferring files between systems is helpfull for someone - here is the source of many problems (Working with the files in Extension "quixplorer" can avoid that, but actually I have no problems with that).

If the reported case assumes another time I'll remember to post more details.

Please, report bugs only when they are reproducable and you can provide instructions how to reproduce them.

The Reason for getting that behavior was that I had a BE-User with uid=0.
In that case the function SC_mod_tools_be_user_index->switchUser($switchUser) doesn't work as expected and behaves like described above.

It is not possible to have a user with uid=0 in a normal way. uid is autoincrement column, which always start with 1. This is not a TYPO3 bug.

All in All TYPO3 works also with a BE-User with uid=0.
The decribed behavior was the only "fault" I remarked over long time with 200-400 users per day on that page.

Reason for changing the mentioned function a bit could be that importing data from other systems like TYPO3 perhaps is a bit easier because one can leave that one incompatible user. Importing data was the reason why that user did exist in my database. Would just be a practicable feature even if it's no bug.

Resolved, no change required:

As soon as you define a table with a primary auto increment field (like for be_users table), and insert a record, the first record will be number 1, not 0.

Please review your import process, this is not a TYPO3 problem.