Get an error after trying to delete events from event viewer

[aostad]

Hi Everyone,
I get a nasty "DB Access Error" (SQL server 2008)after trying to delete events from event viewer page. I've reported the issue in Mantis but my problem is that I can not get rid of the debug backtrace message that shows up every time somebody log-in or log-out.

I'm wondering why the program tries to delete events since then. I've just execute it once but looks like somehow the delete function is called during log-in and log-out.

Here is what the debug backtrace shows:
DB Access Error - debug_print_backtrace() OUTPUT START
==============================================================================
#0 database->exec_query() called at [C:\inetpub\wwwroot\testlink\lib\functions\logger.class.php:696]
#1 tlEventManager->deleteEventsFor() called at [C:\inetpub\wwwroot\testlink\lib\functions\logger.class.php:133]
#2 tlLogger->deleteEventsFor() called at [C:\inetpub\wwwroot\testlink\login.php:207]
#3 renderLoginScreen() called at [C:\inetpub\wwwroot\testlink\login.php:78]
==============================================================================

I've done a couple changes in php.ini and custom config file but no luck so far.

Any help to prevent displaying above message or stop Testlink from calling "delete event" function is much appreciated.

[aostad]

Actually, the error message is displayed as soon as testlink gui shows up. It looks like during initializing gui, the "delete events" function is called; but why?

[aostad]

Can anybody provide some info/hint to prevent Testlink from printing this error message?
Thanks.

[TurboPT]

Can you echo/print the query from that area to see if it appears to be complete?

Look at the query structure: correct spacing around clauses, all values present, quoting is complete, etc...

I don't have SQL server anymore, but maybe we can figure it out based on the query.
[I did NOT see the same error/message using MySQL, just for reference]

[aostad]

That's true the issue shows up only with SQLserver (MsSQL). I have tried it on Mysql and looks OK. It looks like Test link doesn't get tested using SQL server very well. I'm not a fan of MSSQL but we don't make decision and follow company's policy. Almost all medium and big companies use Microsoft product, so Testlink needs to be tested against MSSQL as much as MySQL.

I have attached a file showing the query and issues in Mantis (bug# 0005464).
Thanks for the reply.

[fman]

Is very interesting to see how people complains about how we test on MSSQL, is a pitty that when we ask for support to improve our work we get NO ANSWERS => no people is interested to help us.
You can do a simple thing (I know is not a good answer) use MySQL or Postgres instead of MSSQL, or talk with someone on your company that is willing to provide us with the support we need (i.e. some donations)

if
>> Almost all medium and big companies use Microsoft product, so Testlink needs to be tested against MSSQL as much as MySQL.
I hope all these companies that are paying for MS products will be able to spend some money to support our work.
At least providing an AMAZON SERVER with MSSQL 2008 installed

[aostad]

I hear you and really appreciate your effort. If it was in my hand, I would do everything by donating money or tools to help the community. But unfortunately I don't have that much power.

My 2 cents, if you think Testlink community has problem and it's very hard for them to continue, I suggest change your strategy and slow down in adding features and put more efforts to resolve bugs and make a more stable release. A stable product with fewer features is better than a product with lots of features but problematic in supporting them.

[fman]

1. the issue that seems you are facing has nothing to do with new features, but seem to be something related to MSSQL.
2. if your support can not be money, can be time to help to test MSSQL.
3. trying to support 3 different databases means lot of work, and IMHO we are doing it in an fair way.
4. Till no people is willing to donate time to test on MSSQL, our best tested DB will continue to be MySQL and Postgres.

[TurboPT]

...Almost all medium and big companies use Microsoft product, so Testlink needs to be tested against MSSQL as much as MySQL...

...so it would also help if MS-products [and their cost] did NOT have [untested] issues of their own!

It seems that the IN clause [>25,000 numbers, based on the mantis attachment] has too many values to be handled for MSSQL processing. [the optimizer ends up bailing]

See these links for more info:
@technet
@Microsoft connect

Maybe there could be a way to break the IN-clause listing into chunks of < 10,000 entries? Which, for this particular example, would generate a need for 3 delete queries. (for example, a 10k delete, another 10k delete, and then the remainder)
[realize, of course, that this would be a specific "hack" to support MSSQL's shortcoming]

Which is why:

1. the issue that seems you are facing has nothing to do with new features, but seem to be something related to MSSQL.

[fman]

@TurboPT
thanks a lot for your analisys, than highlight anyway a flaw in our design.
On my regular work unfortunately we also hit the limit with elements in SQL IN CLAUSE.
I'm going to implement the logic to avoid this issue.

Meanwhile the workaround is simple connect to the DB using MS Enterprise manager or other client and truncate transaction and events table.

Your analisys, if useful to remind all the people (dev team included) that when we have this kind of issues we need to start giving a look to the amount of records involved

thanks again!!

[TurboPT]

@TurboPT
thanks a lot for your analisys, than highlight anyway a flaw in our design.
On my regular work unfortunately we also hit the limit with elements in SQL IN CLAUSE.
I'm going to implement the logic to avoid this issue.

Well, did not mean to expose a design flaw...

I must definitely apologize to @aostad for assuming the issue was strictly MSSQL related. [my assumption! ]

Interesting to know that you've seen similar issues with other IN clauses. I have not [yet] "hit" this situation myself, but neither have I encountered an IN clause of that size. For MySQL, they at least claim:

The number of values in the IN list is only limited by the max_allowed_packet value.

so some tweaking of that value could be possible, but I could not find similar details about MSSQL.

[fman]

To continue an endless discussion do not think there is nothing to apologize, because not all the elements to try to understand what was happening were provided from start.
My approach (that would be waste of time) was: ok, will do a fresh install on MSSQL (and I really have done several tests on Windows + MSSQL), and try to delete, and I will be never able to get the error.

regarding limit on IN, this has been a nightmare on my last projects, because if you do not know about it is easy that your dev team use it, and with a QA environment that is not near in record qty to the prod env, you are going to hit the issue only in production!!! (as usual)

Thanks a again.

[aostad]

Thank you all for following up.

We are kind of worry as we don't know how this issue may affect the database. I'm not a DB guy, so just wondering if this issue can damage database and we lose data?

Is it going to be fixed any time soon (e.g. a patch)? Is it possible somebody provide a temporary fix until the issue is fixed?

[fman]

temporary fix is truncate both tables transaction and events by hand each night.

[TurboPT]

... Is it possible somebody provide a temporary fix until the issue is fixed?

The good news, is that the TRUNCATE command/query is the same for both MSSQL and MySQL:

Code: Select all

TRUNCATE TABLE transactions;
TRUNCATE TABLE events;

That's all that needs to be done.