We are looking to possibly expand the use of tickets, but the performance associated with the ticket main view is very poor currently.  I ran a SQL trace while pulling up the ticket main view, and I can see one query taking ~13 seconds to select all attachments with an empty ticketID, but the process takes 30+ seconds just to bring up the view.  Is there another element possibly causing the performance degredation.  I can see in the scripts that SpeedSearch comes into play, but we have never utilized the SpeedSearch server/client.

Slightly off topic, but what is the intended purpose of the ticketing system in SLX?  From what I have read it seems to be support related, and if that is the case, I am wondering if we should be using activities instead of tickets for what we are looking to accomplish, essentially order issue tracking.

**edit**

I meant to post this in the general section under Administration

Are these NULL or blank Attachment.TicketIds in your database? Usually get better results with NULLs. Reindex indexes NIGHTLY in Squeal Server without fail.

How much RAM dedicated to the SQL Server box for the SLX Database? 6.2.6 hmmmmmm.......fairly fast system that I recall (although that's like 6+ years ago).....

About 2/3 of the attchments have an empty ticketID, and roughly another 1/3 have a null ticketID.  I can setup a SQL job to set the ticketID to null when it is equal to ''.  I can also setup another job to specifically reindex the attachment table on a daily basis. 

The physical SQL Server box currently has 4GB of memory, with the /3GB flag. 

I updated the empty values to null, and reindexed the table, bringing the ticket main view opening time from ~75 seconds to ~2 seconds.  I am going to schedule a simple SQL job to set empty ticketIDs to null, but does anyone have any ideas as to why 6.2.6 enters an empty value insead of leaving the ticketID null by default?