You can emphasise standards as much as you like with regard to XML but this is a data entry issue.

If you have required fields on a form within an application...

This might work a bit faster

DECLARE @ProcName sysname ,

@usercredentials sysname

set @procname=''

set @usercredentials='Development'

WHILE @procname is not null

begin

SELECT @procname = min(name)

FROM sysobjects

WHERE xtype='P' and name > @procname and name not like 'dt_%'

IF...

I take your point but DATTIME fields can hold values up to 31-Dec-9999. If you use a date that ridiculously far in the future then you DATEDIFF should always...

Have you considered using LIKE %[^0-9]% as a comparison?

In otherwords if your string contains characters in that are not digits?

I don't know how big your database is but in a live transaction database I would put the growth at fixed growth rather than a percentage.

I have come across this...

I don't have SQL Server available as I write this but my approach would be to do a DATEDIFF between a fixed date in the future and your time col...

I seem to remember that there was a thread about it once before but can't find it now.

The E is something to do with powers of 10. 1E1 =...

Basically NVARCHAR is a double-byte version of VARCHAR.

Some procedures demand that an NVARCHAR is passed and sp_executesql is one of them

If you run

sp_executesql 'SELECT * from sales'

you get an error...

SmallDateTime stores date/time value accurate to the minute

DateTime stores date time values accurate to 3 milliseconds.

exec sp_changedbowner '<>'

Putting your code in stored procs is best practice.

Putting your SELECT DISTINCT into CommandText means that you have to grant read access to your table therefore someone with a valid...

Create a temporary table that holds the extracted IP Address from MT then do an inner join between status and your temp table

ADO tutorial

If you are using ADO to connect to the database have a look at the ADO Stream object.

If you are using .NET use a file stream and Binary reader...

I believe that SQL Clustering has a limit on the number of nodes but assume a server per node plus some form of centralised storage that is available to all...