Error TDeleteExpiredQuarantineThread.Exec |
Post Reply |
Author | |
support GLD
Newbie Joined: 27 June 2006 Location: France Status: Offline Points: 10 |
Post Options
Thanks(0)
Posted: 22 January 2007 at 5:54am |
Hi,
i have this error since i have upgraded to V3.1.3.614 (61648) Exception occurred during TDeleteExpiredQuarantineThread.Execute: 'tblquarantine' : nom d'objet incorrect -- UPDATE tblQuarantine SET Expire = 1 WHERE MsgDate <= :MsgDate AND ( (ServerID = 1) OR (ServerID = 0) OR (ServerID IS NULL) ); If i run this script of my MSSQL database : UPDATE tblQuarantine SET Expire = 1 WHERE MsgDate <= MsgDate AND ( (ServerID = 1) OR (ServerID = 0) OR (ServerID IS NULL) ) This log error is not disappeared and SpamFilter cannot deleted expire e-mails. Any Idea ???? Edited by support GLD |
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
As far as running the script manually, the :MsgDate is actually a parameter in a query, and should be replaced with any date you wish to use as a reference. For example like this:
UPDATE tblQuarantine SET Expire = 1 WHERE MsgDate <= '1/10/2007 12:00:00 AM' AND ( (ServerID = 1) OR (ServerID = 0) OR (ServerID IS NULL) ) In regards to the error, can you see if the above query executes without errors when running it directly within Query Analyzer or the Enterprise Manager? If it works fine, can you double-check to ensure the database user that SpamFilter is using has read/write access to the SpamFilter database and the tblQuarantine table? |
|
support GLD
Newbie Joined: 27 June 2006 Location: France Status: Offline Points: 10 |
Post Options
Thanks(0)
|
Hi,
No error when i execute this query. Spamfilter user have the good rights for reading and writing on database and tblQuarantine table. We use MS SQL Server 2000 Std SP4 on Windows 2003 Srv Std. best regards |
|
support GLD
Newbie Joined: 27 June 2006 Location: France Status: Offline Points: 10 |
Post Options
Thanks(0)
|
If i Downgrade V3.1.3.614 to V3.1.3.605 :
No problem : (14836) Deleted Expired quarantined items (345) best regards |
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
The *only* difference between the two versions is that in 3.1.3.614 the queries have been converted all to lowercase. The error you reported states that the "tblquarantine" object cannot be located. The table name is actually tblQuarantine.
SQL Server is by default not case-sensitive. Did you by any chance configure it for case-sensitive queries? If so, yes, this would cause a problem. |
|
support GLD
Newbie Joined: 27 June 2006 Location: France Status: Offline Points: 10 |
Post Options
Thanks(0)
|
it's a good idea but SQL 2000 is setting on SQL_Latin1_general_CP850_BIN (Latin1-General, binary sort for Unicode Data, SQL Server Sort Order 40 on Code Page 850 for non-Unicode Data. It isn't configured in case sensitive (CI).
best regards |
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
Actually the _BIN (binary sort) option does indeed cause case-sensitive searches:
Binary (_BIN)1 Sorts and compares data in SQL Server tables based on the bit patterns defined for each character. Binary sort order is case sensitive and accent sensitive. Binary is also the fastest sorting order. For more information, see Using Binary Collations. You can change the collation to one that is case insensitive by issuing a query similar to:ALTER DATABASE SpamFilter COLLATE SQL_Latin1_General_CP1_CI_AS |
|
__M__
Groupie Joined: 30 August 2006 Location: Australia Status: Offline Points: 75 |
Post Options
Thanks(0)
|
Roberto, I bet your wishing that you standardized on the lower case from day one now.
It's always the way that something as insignificant ends up causing lots of little problems. Mike |
|
support GLD
Newbie Joined: 27 June 2006 Location: France Status: Offline Points: 10 |
Post Options
Thanks(0)
|
Thank You,
SpamFilter is working fine now with V3.1.3.614 !!! best regards |
|
LogSat
Admin Group Joined: 25 January 2005 Location: United States Status: Offline Points: 4104 |
Post Options
Thanks(0)
|
...and to think the **only** reason that, 4 years ago, we opted to use a mix of lower case/upper case was to make the table names easier to read! I remember specifically the 30 seconds moment of doubt the very first time while creating the tables in MS Access . Yeap, how do I wish we had done otherwise!
|
|
Post Reply | |
Tweet
|
Forum Jump | Forum Permissions You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |
This page was generated in 0.305 seconds.