brian wrote:
> Kamil Srot wrote:
> > Erik Jones wrote
>>>
>>> Also, in your original post you mentioned a "proprietal CMS
>>> system". Is this proprietary to your company or one that you've
>>> purchased? The fact that the same table going on multiple dbs all
>>> being run by that CMS system certainly makes it worthy of suspicion.
>>>
>> This is software developed in our company... so I'm sure it's not
>> duing aby schema manipulation. I'm actually senior developer of this
>> project by accident :-)
>>
>> The strange thing is, all the projects are completelly independend...
>> has its own DB, folder with scripts, different data... just the DB
>> user is the same... so it's higly unprobable, that it'll do 2 similar
>> errors in thow distinct databases at nearly the same time...
>>
>
> IMHO, it's not at all improbable, given that this software is
> connecting to the same databases you are seeing affected by this
> phenomenon. Not to mention that it's proprietary, so fewer eyes have
> gone over it.[1] I suggested earlier grepping for 'drop' in your
> application. Perhaps you should do the same on the CMS.
>
> [1] Not meant as a dig at non-free software.
Understood and I agree. I would accept the possibility to do the most
stupid coding error in the world, but there is simply no statement
manipulating with the schema in the whole project. To be sure, I
searched thru the sources for /drop/i and didn't found anywhere but the
pear framework of PHP (some constants and test patterns of user
statements)... OK, I agree this can be run by some coincidence and so I
have started to log all statements in the logfile... but still I doubt
executing the drop statement is the problem...
Regards,
--
Kamil
