pretty much every db reporting tool out there...from freebies written in Delphi , to crystal reports, etc, all have an RTF object that you just point to the field in...

typically, you might pass a comma delimited string to the procedure, and the proc then uses one of the many SPLIT functions in the Scripts section here on SSC to...

for varchar strings, the = comparison operator strips out ending whitespace.

that is different fromt eh LIKE operator...if you do LIKE 'phrase %', that would not find the item because of...

compatibility level just decides which syntax rules will be applied against any queries hitting the database...it does not change the behind-the-scenes way the database is stored/saved.

that's why you can switch...

all minor syntax stuff; i found three things:

the higher case statement for a.staff said case a.staff andf then had WHEN a.staff...; should be one syntax or the other...

second...

it'd be something like this:

--kick everyone off no matter what!

ALTER DATABASE [YOURDATABASENAME] SET SINGLE_USER WITH ROLLBACK IMMEDIATE

GO

--make sure it's really just for me

ALTER DATABASE [YOURDATABASENAME] SET SINGLE_USER

GO

--do...

your question reads like it came straight from a problem in a textbook...telling us what the required results are...are we doing your homework?

what have you tried so far?

I can tell...

i'd just set the database to single user mode, do my work, and then change it back to multi user;

no fiddling with groups, and you'll know you are the only...

if you use GROUP BY, then every column that is not using a SUM() or AVG() or other grouping operation MUST be in the GROUP BY Statement...so your query would...

you must create the tables with the PK's and FK's...otherwise what you stated....inserting 5 into the child table without checking that the 5 exists in the parent table could occur...that's...

it depends on the locks that the update and insert will demand.

if your update is fiddling with, say, a single row of data, then the update will get a shared...

i guess more information is needed...

nothing gets handled automatically for you as far as PK/FK's go....you might not be doing things in the right order of operation.

did you add new...

there is a real good artical called "calculating work days"[/url] by Jeff Moden here on SQL Server Central that explains the concept and also has a function at the end...

can you show us the execution plan when you run the update? that will tell us exactly what the update is doing, and allow us to offer suggestions like indexes...

there's a script contribution that would load the default trace into a table for review:

Load All 5 Default Trace Files[/url]

maybe that will help