Database

Basically nothing new to add but since you've asked for opinions... Having two tables is absolutely, definitely and undeniably :) the correct way because of: - maintainability - (quite) easy to query regardless of the reporting needs - flexibility when quering - efficiency Depending on the needs I would even concider having three separate (typed) rows, one for On peak value, second for off peak and third for the total (if it cannot be calculated from the data). If the total can be calculated from the data I wouldn't store it, at least not in these tables. Best regards, mika The need to optimize rises from a bad design.My articles[^]

You can download the management studio from here: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c243a5ae-4bd1-4e3d-94b8-5a0f62bf7796&DisplayLang=en[^]. However, if you want, you can use the newer (SQL 2008) management studio also to operate older (SQL 2005) databases. It's located: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=08E52AC2-1D62-45F6-9A4A-4B76A8564A2B[^] The need to optimize rises from a bad design.My articles[^]

You're welcome. Glad that it helped :) The need to optimize rises from a bad design.My articles[^]

I am facing the same problem plz send me the solution on my mail address abdullah555@yahoo.com

What I have done in the past is to periodically delete rows older than some threshold. If you like, you can use a trigger to also write them to some archive table.

You're welcome :) The need to optimize rises from a bad design.My articles[^]

No problem :) The need to optimize rises from a bad design.My articles[^]

Hi, I noticed that you solved the problem by using cursor, which is fine but fot performance reasons I think that if we could find a set-based solution it'd be best. So if I understood correctly you need each individual ID in your result set and sums for them, so could the query be something like: SELECT d.Day, d.[Day Of Year], (SELECT SUM(Points) FROM #tickets t WHERE t.[Changed Date] <= d.[Day Of Year] AND t.Id = sub1.Id) AS Points FROM #sprintDays d, (SELECT DISTINCT t.Id FROM #tickets t) sub1 Just correct me if If I'm going to wrong direction. The need to optimize rises from a bad design.My articles[^]

Hi, Just throwing few built-in mechanisms which could be usable (without knowing the backgrounds for your audit needs). Have you had a look at Change Tracking and Change Data Capture: http://msdn.microsoft.com/en-us/library/cc280519.aspx[^]. Then SQL Server also has several different mechanisms for pure auditing: http://msdn.microsoft.com/en-us/library/cc280526.aspx[^] but some of those are edition specific. The need to optimize rises from a bad design.My articles[^]

Here is what I would do. From your app I would query the users/logins of the database, if your functional id (this describes the identity your app is going to use to communicate with the database. create the user with user name and password using sql authentication. Give the user RO rights on all the objects (views and tables) change your connection to use the RO credentials. I seriously don't know if a RO connection is valid, I have certainly never heard of anyone using one. Never underestimate the power of human stupidity RAH

hi thanks for your rep. so how can use datareder to get data from table any examples? waiting for your kind rep.

Then I found a simpler way when I actually worked the query. SELECT TOP 2 contentID, RC FROM (SELECT contentID, SUM(readsCounter) RC FROM Book1 AS B --WHERE ReadDate BETWEEN this AND that GROUP BY contentID) D ORDER BY RC desc Note the where clause will be required when the data set is larger Never underestimate the power of human stupidity RAH

No problem :) The need to optimize rises from a bad design.My articles[^]

As already said, basics of SQL should be learned first. But when you start to go deeper, have a look at these excellent books: Amazon's Complete Selection of Joe Celko Books[^] The need to optimize rises from a bad design.My articles[^]

There's an article in CP which could be benefitial for you. Even though the article has some issues there are mechanisms you could try if the problem is still relevant: Point In Time Restore[^] The need to optimize rises from a bad design.My articles[^]

Must say that you found an excellent article for this issue ! :) The need to optimize rises from a bad design.My articles[^]

It's good that you have excellent tools to administer the database but in order to use the tools correctly you must understand what happens "under the hood", so one of the "must have" books is: http://www.amazon.com/Introduction-Database-Systems-8th/dp/0321197844[^] Also see the section "Customers Who Bought This Item Also Bought..." The need to optimize rises from a bad design.My articles[^]

reza assar wrote: any other suggestion? It might speed up things if you search (Ctrl-F) the entire solution for "SqlConnection" and add a using-block to each instance found. That would, in theory, dispose of your connection once processing exits the defined scope, and thus, also close it. I are Troll :suss: