SELECT *
FROM   dbo.sysfiles 
WHERE  (status & 0x40) <> 0

So if you’re like me and don’t have all the bit compares memorized for all the tables you probably didn’t know that this is how (in SQL 2000) you would query the current database to find all the transaction log files. 

Every now and again I take for granted the major jump that was SQL 2000 to SQL 2005 and little things like this just show me how much happier I am working in a SQL 2005/2008 environment. 

Let me channel my inner Naughty By Nature here:

You down with DMV…. yeah you know me
You down with DMV… yeah you know me

(Sorry I’m still hurting from not winning SQL Fool’s Rap Contest  )

DAMN YOU  My humble congratulations to Steve “Flavor Flav” Jones

Now if you were to come across this code:

SELECT * 

FROM   sys.database_files

WHERE  type_desc = 'LOG'



Wouldn’t you have a much better idea as to what the query is trying to accomplish?

Anyways just another (albeit small) reason why I’m glad to be leaving SQL 2000 in the past.

Enjoy!!

Short Answer: YES

It had been a while since I worked with SQL 2000 Replication so I was fairly confident that you could but wasn’t willing to just go and do it without a proper test first.

I took at copy of the database that I was looking to do this on and built myself a little test enivornment.  I made sure my database was in full recovery mode… setup a transactional replication publication, distributor, and subscriber identical to the environment I’m wanting to do this on.  I inserted, updated, and deleted some rows just to make sure everything was tickity-boo before doing my test.

I altered the publisher database and set the recovery mode to Simple without doing anything special to replication… I did more inserts, updates, and deletes and everything flowed through smoothly.  I switch it back to Full Recovery Mode and lather, rinse, repeat and everything still worked fine.

When I Binged the question I didn’t get many (or any) hits that applied.  One link I went to (totally unrelated) was very scary/interesting… A user asked about using Simple Recovery Mode and whether Replication will work or not… someone told them that you can’t use simple recovery mode cause transactional replication depends on the transaction log and that a checkpoint will flush everything out (replicated or not) and cause replication to fail. 

*sigh* another example of why you don’t want to take everything you read at face value without investigating on your own.  Some answers are just clearly wrong (like the one above)… while others are kind of right depending on the situation and need.  My replication test I just performed worked successfully for me but just for arguements sake what if there was a publication setting somewhere that would invalidate your publication and force you into a reinitializing your subscribers?

I guess the moral of the story is something that has been commented on by many people in the community.  The internet is a great resource for finding information and answers but at the end of the day it’s up to YOU to test and ensure that the information and answers you get are right for you and your environment.

Enjoy!!!

So my blackberry started buzzing at 11:30 pm one evening… well twice actually. The first buzz was a

“Are you still awake” msg and the second one was

“When you get up… in TSQL how do I do ntext_field1 + ntext_field2 as newfield?”

being 1/2 asleep at the time I decided I’d leave it till morning cause my wife always gives me hell when I email in bed LOL So the next morning I get up and start writing an email on string concatenation… then I reread his original questions and it wasn’t just a question on string concatenation it was about ntext concatenation.

so I gave the BOL link to UPDATETEXT and gave him a quick example to work with:

CREATE TABLE tblSQLServerPediaMembers (id INT NOT NULL, SomeTextValue NTEXT NULL)

UPDATETEXT tblSQLServerPediaMembers.SomeTextValue @ptr NULL 0 '... now leave me alone LOL'
GO
SELECT * FROM tblSQLServerPediaMembers
GO
DROP TABLE tblSQLServerPediaMembers

At the end of it all I remember him telling me about a new app he was working on so I also mentioned that if he was on SQL 2005 or SQL 2008 that he should replace his ntext with nvarchar(max) because ntext is being deprecated and that nvarchar(max) can use “normal” string concatenation instead of needing to use the UPDATETEXT command.

CREATE TABLE tblSQLServerPediaMembers (id INT NOT NULL, SomeTextValue NVARCHAR(MAX) NULL)

UPDATE tblSQLServerPediaMembers
SET SomeTextValue = SomeTextValue + '... now leave me alone LOL'
GO
SELECT * FROM tblSQLServerPediaMembers
GO
DROP TABLE tblSQLServerPediaMembers

I didn’t hear from him again this weekend so I think he got what he needed. So for those of you still on SQL Server 2000 UPDATETEXT is your string concatenation friend and once you’re >= SQL Server 2005 you can forget all about UPDATETEXT (well until your blackberry starts vibrating at 11:30 at night hehehe)

Enjoy!!

SQL 2000 – http://msdn.microsoft.com/en-us/library/aa175266.aspx
SQL 2005 – http://msdn.microsoft.com/en-us/library/ms143761(SQL.90).aspx
SQL 2008 – http://msdn.microsoft.com/en-us/library/cc645993.aspx

These 3 websites give you a very detailed look into each version and edition of SQL Server and the features avaliable for each. It always easiest to recommend the newest and hottest for your customers but without evaluating their needs and cross referencing that with the feature lists above they may be spending more money then they need.

(that being said I don’t think recommending a SQL Server 2000 solution would be a great idea either hehehe )