Since your using a numeric the left works fine , however after a little experimenting I found that if your gonna deal with string data varchar then substring works...

I think the answer is quite clear for me , the guy who writes the code owns it esp since if there is a issue in production the dba will...

Since SQL express has no SQL Agent you will need to script out a backup command and have it scheduled using windows scheduler.

i.e create a batch file and call sqlcmd...

http://www.sqlservercentral.com/Forums/Topic1126293-391-1.aspx#bm1126863

this has been discussed in the above post as well. Since the users are connecting via terminal services and using sql logins theres not much you can really do.

Are u using filestream for the catalog directory ?

If so this might help

http://technet.microsoft.com/en-us/library/bb895334.aspx

Any reason why you cannot use C_ID itself , if you need an other then try using the row_number function or a guid or a computed column. I cant see...

Thanks I had suggested the same to our DBA folks , haven't heard back from them though 😀

Is it worth the effort to identify table with high index fragmentation and then update stats for those tables more frequently instead of doing a full scan

is it possible to try backup log with truncate with no log followed by the database backup, important to backup the data soon after to prevent data loss.

You can search for any center which conducts MCITP certification they would most likely have a course on MS SQL DBA.

Salut

Hi

This would remove scope for inserting a range between 1 and 100...

DECLARE @tbl AS TABLE (ID INT IDENTITY(1,1), LNAme VARCHAR(50),FrmPoint INT, ToPoint INT)

INSERT INTO @tbl (LNAme, FrmPoint, ToPoint)

SELECT 'Level1',101,200

INSERT INTO @tbl (LNAme, FrmPoint, ToPoint)

SELECT 'Level2',201,300

INSERT INTO @tbl (LNAme, FrmPoint, ToPoint)

SELECT...

I admit that replication is not only for scalability however from the article you mentioned

The definition of high availability below hardly applies to replication I think.

A high-availability solution...

the query plan looks fine

Could you try running the client stats once more after executing

DBCC DROPCLEANBUFFERS

DBCC FREEPROCCACHE

http://msdn.microsoft.com/en-us/library/ms187762.aspx

http://msdn.microsoft.com/en-us/library/ms174283.aspx

Probably this will make the results more accurate.