POST THE CODE

might be worth trying

>=

''

then.

Yes it would.

Agree float is absolutely inappropriate for a surrogate key.

The efficency of a key column depends mainly on two things: how big it is, and how straightforwardly it is compared.

Using character data...

POST THE CODE !!!!

There's no way you should have a trigger that takes 20s. Optimise the code or get it out of the trigger and do it some other way. Doing it in a...

There is no advantage from the POV of storage or efficiency in reducing the maximum size of varchar fields. The only reason to do so is to avoid overrunning the...

Because all inserts have to occur at the 'same' point i.e. at the end.

Of course there are about 587 other considerations which also feed into the decision process...

>(pretty cool... even though he didn't test it {had 2 "AS" in it}, he almost got it right)...

Even cooler when no-one realises you haven't tested it!

BTW, MAX() might be...

It's only a problem if access to this table is done in a multiple-statement transaction, or if for some bizarre reason you used a massive query to read and write from...

Jeff M: >If someone was foolish enough to build an Oracle-like "sequence table" (for next ID's and the like), first, find them and shoot them out of a cannon...

Both tables being scanned, one repeatedly (the lazy spool.) Put a compound index on all join columns on both tables, in the same order on both tables. Add any remaining columns...

EM = Enterprise Manager

SSMS = SQL Server Management Studio

For point-in-time, look at sysprocesses. If a series of snapshots rather than a complete audit is ok, you could just poll it every few seconds. I don't think that would...

It's not necessarily a mistake to store the values as varchar. Often ID 'numbers' are not really numbers, even though they may be restricted to a very limited subset of...