multiple deletes with a stored procedure

Just wondering if this is good form:

Alter Procedure "mySPName"
@.UniqueID int
AS
set nocount on
set xact_abort off

DELETE FROM tblNameOne
WHERE
(tblNameOne.UniqueID = @.UniqueID)

DELETE FROM tblNameTwo
WHERE
(tblNameTwo.UniqueID = @.UniqueID)

Is it a good idea to run multiple detele statements within one SP?
thanks,
lqOn 8 Apr 2004 12:30:55 -0700, Lauren Quantrell wrote:

>Just wondering if this is good form:

Looks fine to me, except I'd prefer set xact_abort on. But that's a
general comment, your situation mught demand this option to be off.

Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)|||Thanks,
I am having a situation were the SQL server experiences every now and
then excessive blocking errors, sometimes around the time of execution
of this type of stored procedure, sometimes around the time of an SP
where I'm running multiple INSERT queries with one SP. I'm trying to
identify where the problem may be.

I'm wondering if you could tell me what the use of GO or RETURN is and
if I need them in this sort of SP?
lq

Hugo Kornelis <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message news:<v1bb70td57mtifd8le40ot4kv9gp118as9@.4ax.com>...
> On 8 Apr 2004 12:30:55 -0700, Lauren Quantrell wrote:
> >Just wondering if this is good form:
> Looks fine to me, except I'd prefer set xact_abort on. But that's a
> general comment, your situation mught demand this option to be off.
> Best, Hugo|||On 9 Apr 2004 06:42:55 -0700, Lauren Quantrell wrote:

>Thanks,
>I am having a situation were the SQL server experiences every now and
>then excessive blocking errors, sometimes around the time of execution
>of this type of stored procedure, sometimes around the time of an SP
>where I'm running multiple INSERT queries with one SP. I'm trying to
>identify where the problem may be.

I don't know much about blocking. The only thing I know is that you
can use sp_who to identify which process all other processes are
waiting for. The only action I have ever taken in these situations was
to either kill the blocking process or tell the complaining users that
this process was too important to postpone until the evening.

If you find a procedure like this to be the cause of blocking, there
are probably ways to improve this. However, I don't know how to do
that. Maybe you should ask a new question, making sure that "blocking"
is in the subject line. Also, note that there are a lot of groups
devoted to SQL Server in the microsoft.public.sqlserver hierarchy. A
question about blocking could go in either .programming or .server.

>I'm wondering if you could tell me what the use of GO or RETURN is and
>if I need them in this sort of SP?

RETURN is used to exit immediately from a stored procedure or trigger.
Check Books Online for more detailed description and examples. Use it
if you detect a situation where the remaining statements in the
procedure should not be executed.

GO means "end of batch". It is intercepted by Query Analyzer (as well
as OSQL, ISQL and probably other tools as well) and prompts them to
send everything to the server. Therefor, you can't put GO inside a
procedure. Example:

Create procedure Testit
as
select * from sysobjects
go
select * from sysfiles
go

Execute this, and all rows in sysfiles will be listed. Next, execute
"sp_helptext Testit" and you'll see that only the select from
sysobjects made it into the procedure. The other select was sent as a
seperate batch and therefor executed immediately.

Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)|||If i am not wrong, i think the GO statment is used for Batch Termination.
Some of the SQL Statments don't allow some Commands to be executed along
with DDL. So the word GO can be used to tell the SQL Server that one batch
finished and the other batch is ready. The return statement can be used when
checking for error codes and returning an error code(from a procedure) to
the appropriate procedure/SQL.

"Lauren Quantrell" <laurenquantrell@.hotmail.com> wrote in message
news:47e5bd72.0404090542.db112d9@.posting.google.co m...
> Thanks,
> I am having a situation were the SQL server experiences every now and
> then excessive blocking errors, sometimes around the time of execution
> of this type of stored procedure, sometimes around the time of an SP
> where I'm running multiple INSERT queries with one SP. I'm trying to
> identify where the problem may be.
> I'm wondering if you could tell me what the use of GO or RETURN is and
> if I need them in this sort of SP?
> lq
>
> Hugo Kornelis <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
news:<v1bb70td57mtifd8le40ot4kv9gp118as9@.4ax.com>...
> > On 8 Apr 2004 12:30:55 -0700, Lauren Quantrell wrote:
> > >Just wondering if this is good form:
> > Looks fine to me, except I'd prefer set xact_abort on. But that's a
> > general comment, your situation mught demand this option to be off.
> > Best, Hugo|||Have you looked at triggers? We've got an idiot vendor (who should
be gone by the end of the year) who implemented their referential
integrity with triggers, rather than real foreign keys.
We make up for that with an excessive use of cursors and nolock
hints, but if you have the option of actually fixing the trigger,
it would be better.

Bill

Lauren Quantrell wrote:

> Thanks,
> I am having a situation were the SQL server experiences every now and
> then excessive blocking errors, sometimes around the time of execution
> of this type of stored procedure, sometimes around the time of an SP
> where I'm running multiple INSERT queries with one SP. I'm trying to
> identify where the problem may be.
> I'm wondering if you could tell me what the use of GO or RETURN is and
> if I need them in this sort of SP?
> lq
>
> Hugo Kornelis <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message news:<v1bb70td57mtifd8le40ot4kv9gp118as9@.4ax.com>...
>>On 8 Apr 2004 12:30:55 -0700, Lauren Quantrell wrote:
>>
>>
>>>Just wondering if this is good form:
>>
>>Looks fine to me, except I'd prefer set xact_abort on. But that's a
>>general comment, your situation mught demand this option to be off.
>>
>>Best, Hugo

multiple deletes cross tables

Hi,
I have a hierarchy of tables, like "Company" on top, with "Offices"
underneath and "People" underneath those and "Contact info" under those,
etc.
Now, a record gets deleted in the "Company" table. This means the Offices
and People attached to them get deleted also.
I could do this via triggers to ensure consistency, or via a stored
procedure:
CREATE PROCEDURE myspDeleteCompany ( @.Id INT )
{
-- delete other stuff first belonging to the company
DELETE FROM Stuff WHERE ParentId = @.Id
-- delete offices first
EXEC myspDeleteOffices( @.Id );
-- delete self
DELETE FROM Companies WHERE Id=@.Id
}
CREATE PROCEDURE myspDeleteOffices ( @.ParentId )
{
-- delete people first
DELETE FROM People WHERE ParentId IN (SELECT Id FROM Companies WHERE
ParentId = @.Id)
-- delete offices
DELETE FROM Companies WHERE ParentId = @.Id
}
Triggers would be better, but I need to use procedures because I am not
really deleting records, rather setting up a flag Deleted=1. So all DELETE
statements are actually UPDATE <record> SET Deleted=1. This gets tricky when
using triggers. So let's forget about it.
Questions:
- myspDeleteOffices needs to delete people. For this I have to list all
offices first and then delete people that work at that office. Would a
cursor not be better?
- More importantly, deleting people or offices could fail.. in which case
things from the Stuff table may have already been deleted. To roll these
changes back, so that either everything gets deleted (all steps succeed) or
everything gets restored, what should I do? Use transactions?
Something like this?
CREATE PROCEDURE myspDeleteCompany ( @.Id INT )
{
BEGIN TRANSACTION
-- delete other stuff first belonging to the company
DELETE FROM Stuff WHERE ParentId = @.Id
-- delete offices first
EXEC myspDeleteOffices( @.Id );
-- delete self
DELETE FROM Companies WHERE Id=@.Id
COMMIT TRANSACTION
}
If an error occurs, does the transaction get rolled back automatically
without me calling ROLLBACK TRANSACTION ?
Usually when an error occurs, the query aborts, so I wouldn't be able to
call ROLLBACK after that.
Just have no clue how this is done in real life situations.
LisaLisa
Have you considered using INSTEAD OF DELETE Triggers?
"Lisa Pearlson" <no@.spam.plz> wrote in message
news:%23twTI99SFHA.1896@.TK2MSFTNGP14.phx.gbl...
> Hi,
> I have a hierarchy of tables, like "Company" on top, with "Offices"
> underneath and "People" underneath those and "Contact info" under those,
> etc.
> Now, a record gets deleted in the "Company" table. This means the Offices
> and People attached to them get deleted also.
> I could do this via triggers to ensure consistency, or via a stored
> procedure:
> CREATE PROCEDURE myspDeleteCompany ( @.Id INT )
> {
> -- delete other stuff first belonging to the company
> DELETE FROM Stuff WHERE ParentId = @.Id
> -- delete offices first
> EXEC myspDeleteOffices( @.Id );
> -- delete self
> DELETE FROM Companies WHERE Id=@.Id
> }
> CREATE PROCEDURE myspDeleteOffices ( @.ParentId )
> {
> -- delete people first
> DELETE FROM People WHERE ParentId IN (SELECT Id FROM Companies WHERE
> ParentId = @.Id)
> -- delete offices
> DELETE FROM Companies WHERE ParentId = @.Id
> }
> Triggers would be better, but I need to use procedures because I am not
> really deleting records, rather setting up a flag Deleted=1. So all DELETE
> statements are actually UPDATE <record> SET Deleted=1. This gets tricky
when
> using triggers. So let's forget about it.
> Questions:
> - myspDeleteOffices needs to delete people. For this I have to list all
> offices first and then delete people that work at that office. Would a
> cursor not be better?
> - More importantly, deleting people or offices could fail.. in which case
> things from the Stuff table may have already been deleted. To roll these
> changes back, so that either everything gets deleted (all steps succeed)
or
> everything gets restored, what should I do? Use transactions?
> Something like this?
> CREATE PROCEDURE myspDeleteCompany ( @.Id INT )
> {
> BEGIN TRANSACTION
> -- delete other stuff first belonging to the company
> DELETE FROM Stuff WHERE ParentId = @.Id
> -- delete offices first
> EXEC myspDeleteOffices( @.Id );
> -- delete self
> DELETE FROM Companies WHERE Id=@.Id
> COMMIT TRANSACTION
> }
> If an error occurs, does the transaction get rolled back automatically
> without me calling ROLLBACK TRANSACTION ?
> Usually when an error occurs, the query aborts, so I wouldn't be able to
> call ROLLBACK after that.
> Just have no clue how this is done in real life situations.
> Lisa
>|||You can do that with DRI (declaritive referential integrity) where you can
modify (Delete,Update) the "parent" which automatically takes affect on all
"children" referenced to this.
Example:
ALTER TABLE [dbo].[Order Details] ADD
CONSTRAINT [FK_Order_Details_Orders] FOREIGN KEY
(
[OrderID]
) REFERENCES [dbo].[Orders] (
[OrderID]
) ON DELETE CASCADE ON UPDATE CASCADE ,
CONSTRAINT [FK_Order_Details_Products] FOREIGN KEY
(
[ProductID]
) REFERENCES [dbo].[Products] (
[ProductID]
)
GO
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
--
"Lisa Pearlson" <no@.spam.plz> schrieb im Newsbeitrag
news:%23twTI99SFHA.1896@.TK2MSFTNGP14.phx.gbl...
> Hi,
> I have a hierarchy of tables, like "Company" on top, with "Offices"
> underneath and "People" underneath those and "Contact info" under those,
> etc.
> Now, a record gets deleted in the "Company" table. This means the Offices
> and People attached to them get deleted also.
> I could do this via triggers to ensure consistency, or via a stored
> procedure:
> CREATE PROCEDURE myspDeleteCompany ( @.Id INT )
> {
> -- delete other stuff first belonging to the company
> DELETE FROM Stuff WHERE ParentId = @.Id
> -- delete offices first
> EXEC myspDeleteOffices( @.Id );
> -- delete self
> DELETE FROM Companies WHERE Id=@.Id
> }
> CREATE PROCEDURE myspDeleteOffices ( @.ParentId )
> {
> -- delete people first
> DELETE FROM People WHERE ParentId IN (SELECT Id FROM Companies WHERE
> ParentId = @.Id)
> -- delete offices
> DELETE FROM Companies WHERE ParentId = @.Id
> }
> Triggers would be better, but I need to use procedures because I am not
> really deleting records, rather setting up a flag Deleted=1. So all DELETE
> statements are actually UPDATE <record> SET Deleted=1. This gets tricky
> when using triggers. So let's forget about it.
> Questions:
> - myspDeleteOffices needs to delete people. For this I have to list all
> offices first and then delete people that work at that office. Would a
> cursor not be better?
> - More importantly, deleting people or offices could fail.. in which case
> things from the Stuff table may have already been deleted. To roll these
> changes back, so that either everything gets deleted (all steps succeed)
> or everything gets restored, what should I do? Use transactions?
> Something like this?
> CREATE PROCEDURE myspDeleteCompany ( @.Id INT )
> {
> BEGIN TRANSACTION
> -- delete other stuff first belonging to the company
> DELETE FROM Stuff WHERE ParentId = @.Id
> -- delete offices first
> EXEC myspDeleteOffices( @.Id );
> -- delete self
> DELETE FROM Companies WHERE Id=@.Id
> COMMIT TRANSACTION
> }
> If an error occurs, does the transaction get rolled back automatically
> without me calling ROLLBACK TRANSACTION ?
> Usually when an error occurs, the query aborts, so I wouldn't be able to
> call ROLLBACK after that.
> Just have no clue how this is done in real life situations.
> Lisa
>|||Lisa,
Its Ok if you are deleteing or Updating, you can use a trigger for the
purpose. This is what i believe.
for myspDeleteOffices, u can write a simple delete query instead of going
for Cursors. Cursors bring down the performance of the system because they
involve iterations and buffer storage
As u said, you can use transactions if u feel the batch job fails
thanks and regards
Chandra
"Lisa Pearlson" wrote:

> Hi,
> I have a hierarchy of tables, like "Company" on top, with "Offices"
> underneath and "People" underneath those and "Contact info" under those,
> etc.
> Now, a record gets deleted in the "Company" table. This means the Offices
> and People attached to them get deleted also.
> I could do this via triggers to ensure consistency, or via a stored
> procedure:
> CREATE PROCEDURE myspDeleteCompany ( @.Id INT )
> {
> -- delete other stuff first belonging to the company
> DELETE FROM Stuff WHERE ParentId = @.Id
> -- delete offices first
> EXEC myspDeleteOffices( @.Id );
> -- delete self
> DELETE FROM Companies WHERE Id=@.Id
> }
> CREATE PROCEDURE myspDeleteOffices ( @.ParentId )
> {
> -- delete people first
> DELETE FROM People WHERE ParentId IN (SELECT Id FROM Companies WHERE
> ParentId = @.Id)
> -- delete offices
> DELETE FROM Companies WHERE ParentId = @.Id
> }
> Triggers would be better, but I need to use procedures because I am not
> really deleting records, rather setting up a flag Deleted=1. So all DELETE
> statements are actually UPDATE <record> SET Deleted=1. This gets tricky wh
en
> using triggers. So let's forget about it.
> Questions:
> - myspDeleteOffices needs to delete people. For this I have to list all
> offices first and then delete people that work at that office. Would a
> cursor not be better?
> - More importantly, deleting people or offices could fail.. in which case
> things from the Stuff table may have already been deleted. To roll these
> changes back, so that either everything gets deleted (all steps succeed) o
r
> everything gets restored, what should I do? Use transactions?
> Something like this?
> CREATE PROCEDURE myspDeleteCompany ( @.Id INT )
> {
> BEGIN TRANSACTION
> -- delete other stuff first belonging to the company
> DELETE FROM Stuff WHERE ParentId = @.Id
> -- delete offices first
> EXEC myspDeleteOffices( @.Id );
> -- delete self
> DELETE FROM Companies WHERE Id=@.Id
> COMMIT TRANSACTION
> }
> If an error occurs, does the transaction get rolled back automatically
> without me calling ROLLBACK TRANSACTION ?
> Usually when an error occurs, the query aborts, so I wouldn't be able to
> call ROLLBACK after that.
> Just have no clue how this is done in real life situations.
> Lisa
>
>|||All of this seems like it would work ... however, what is the long term
impact of building a system like this? It seems like you will end up having
to write regular queries that skip over records that have the deleted flag
set to one. Over time, you will end up querying on a field that may not hav
e
good selectively which will result in scans.
If you need to maintain deleted data you may want to consider using DRI with
cascading deletes and then use delete triggers move your deleted data to
archive audit tables. This also typically has the benefit of adding additia
l
audit data such as users names, dates and times to your audit record.
"Chandra" wrote:
> Lisa,
> Its Ok if you are deleteing or Updating, you can use a trigger for the
> purpose. This is what i believe.
> for myspDeleteOffices, u can write a simple delete query instead of going
> for Cursors. Cursors bring down the performance of the system because they
> involve iterations and buffer storage
>
> As u said, you can use transactions if u feel the batch job fails
> thanks and regards
> Chandra
>
> "Lisa Pearlson" wrote:
>|||That's a SQL 8/2000 feature, isn't it?
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:%23Nok1$9SFHA.2756@.tk2msftngp13.phx.gbl...
> Lisa
> Have you considered using INSTEAD OF DELETE Triggers?
> "Lisa Pearlson" <no@.spam.plz> wrote in message
> news:%23twTI99SFHA.1896@.TK2MSFTNGP14.phx.gbl...
> when
> or
>|||Yes. Both cascading foreign key as well as instead of triggers were introduc
ed in 2000.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Lisa Pearlson" <no@.spam.plz> wrote in message news:edfskS$SFHA.3056@.TK2MSFTNGP14.phx.gbl..
.
> That's a SQL 8/2000 feature, isn't it?
> "Uri Dimant" <urid@.iscar.co.il> wrote in message news:%23Nok1$9SFHA.2756@.t
k2msftngp13.phx.gbl...
>|||The deleted flag is used for 2 reasons:
- Deleted records can be undeleted.
- All fields with deleted flag also have updated (timestamp) flag. This way
client program can poll 'changed records' efficiently
In SQL Server 2000 I heard you can use something like service that can
notify clients in some way of changed records. Mine was developed for SQL 7.
And you can create a type of maintanance plan that executes a DELETE FROM
<tablename> WHERE Deleted=1 AND TIMEDIFF(NOW(), Updated) > 1 month (or
something like this)
This should not impact performance too bad.. but you are right that moving
it to another "deleted" table would be better, because I do have to be
consistent to always check "deleted!=1" (because deleted can be 0 or NULL)
It's a bit of a mess :)
But I can do 'deleted' automatically with cascaded updates or something?
Lisa
"Chris Stransky" <ChrisStransky@.discussions.microsoft.com> wrote in message
news:821AB7CF-FABC-4C5B-A5E5-C134E9102DCC@.microsoft.com...
> All of this seems like it would work ... however, what is the long term
> impact of building a system like this? It seems like you will end up
> having
> to write regular queries that skip over records that have the deleted flag
> set to one. Over time, you will end up querying on a field that may not
> have
> good selectively which will result in scans.
> If you need to maintain deleted data you may want to consider using DRI
> with
> cascading deletes and then use delete triggers move your deleted data to
> archive audit tables. This also typically has the benefit of adding
> additial
> audit data such as users names, dates and times to your audit record.
> "Chandra" wrote:
>|||You could undelete by moving records back into the main table. Your undelet
e
function would have to be smart enough to move child records back.
Or
If you use DRI and include the deleted field in the PK then the cascade
would handle the child updates for you in all cases.
If you are worried about always selecting records that are not deleted you
could create a view that includes the deleted column ... but limit it to onl
y
undeleted records. All you have to do then is ensure that the view permits
updates that allow records to disappear from the view on update. That's in
BOL.
"Lisa Pearlson" wrote:

> The deleted flag is used for 2 reasons:
> - Deleted records can be undeleted.
> - All fields with deleted flag also have updated (timestamp) flag. This wa
y
> client program can poll 'changed records' efficiently
> In SQL Server 2000 I heard you can use something like service that can
> notify clients in some way of changed records. Mine was developed for SQL
7.
> And you can create a type of maintanance plan that executes a DELETE FROM
> <tablename> WHERE Deleted=1 AND TIMEDIFF(NOW(), Updated) > 1 month (or
> something like this)
> This should not impact performance too bad.. but you are right that moving
> it to another "deleted" table would be better, because I do have to be
> consistent to always check "deleted!=1" (because deleted can be 0 or NULL)
> It's a bit of a mess :)
> But I can do 'deleted' automatically with cascaded updates or something?
> Lisa
>
> "Chris Stransky" <ChrisStransky@.discussions.microsoft.com> wrote in messag
e
> news:821AB7CF-FABC-4C5B-A5E5-C134E9102DCC@.microsoft.com...
>
>|||On Thu, 28 Apr 2005 12:45:12 +0200, Lisa Pearlson wrote:
(snip)
>Questions:
>- myspDeleteOffices needs to delete people. For this I have to list all
>offices first and then delete people that work at that office. Would a
>cursor not be better?
Hi Lisa,
No - cursors are almost never better. In over 99.9% of all casees, they
are actually far worse.
You'll find that the cascaded delete is lots easier to carry out if you
start at the bottom of the hierarchy - delete Contact Info for all
people in an office of the ex-company first, then all people in an
office of the ex-company, then all offices of the ex-company, and save
the deleting of the company to the last.

>- More importantly, deleting people or offices could fail.. in which case
>things from the Stuff table may have already been deleted. To roll these
>changes back, so that either everything gets deleted (all steps succeed) or
>everything gets restored, what should I do? Use transactions?
Yep.

>Something like this?
>CREATE PROCEDURE myspDeleteCompany ( @.Id INT )
>{
> BEGIN TRANSACTION
> -- delete other stuff first belonging to the company
> DELETE FROM Stuff WHERE ParentId = @.Id
> -- delete offices first
> EXEC myspDeleteOffices( @.Id );
> -- delete self
> DELETE FROM Companies WHERE Id=@.Id
> COMMIT TRANSACTION
>}
>If an error occurs, does the transaction get rolled back automatically
>without me calling ROLLBACK TRANSACTION ?
>Usually when an error occurs, the query aborts, so I wouldn't be able to
>call ROLLBACK after that.
No, you'll have to add error handling. Without that, the execution would
continue and the transaction commited, even though some of your
statements have failed. That would ruin your consistency!
Check these articles, that describe error handling in detail:
http://www.sommarskog.se/error-handling-I.html
http://www.sommarskog.se/error-handling-II.html
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)

Multiple Cascade Path restriction

When using RI to do cascade deletes, why is there a restriction based on
multiple cascade paths ?
Yes I know how to get round the problem, but our application works on the
other major DBs so we're not going to change it just to work on one, so
we're forced to use triggers just one this one DB.. Can we log an
enhancement request to remove this ridiculous restriction ?
Thanks
AdrianIt's a matter of implementation. Before SQL Server 2000 cascading RI weren't
supported at all.
There are scenarios where multiple cascade paths make sense, of course. I
guess that you will see it in the product at some point in the future
(probably with the limit on cyclic relationships).
And yes, you can send your request to sqlwish@.microsoft.com. More requests
they get, better are the chances you will see it in the product at some
point.
BG, SQL Server MVP
www.SolidQualityLearning.com
"Adrian Parker" <apparker@.nospam.nospam> wrote in message
news:uhp88p1PFHA.3076@.TK2MSFTNGP12.phx.gbl...
> When using RI to do cascade deletes, why is there a restriction based on
> multiple cascade paths ?
> Yes I know how to get round the problem, but our application works on the
> other major DBs so we're not going to change it just to work on one, so
> we're forced to use triggers just one this one DB.. Can we log an
> enhancement request to remove this ridiculous restriction ?
> Thanks
> Adrian
>
>|||Thanks for the reply.. request duly sent :)
"Itzik Ben-Gan" <itzik@.REMOVETHIS.SolidQualityLearning.com> wrote in message
news:O6z9fx1PFHA.1096@.TK2MSFTNGP12.phx.gbl...
> It's a matter of implementation. Before SQL Server 2000 cascading RI
> weren't supported at all.
> There are scenarios where multiple cascade paths make sense, of course. I
> guess that you will see it in the product at some point in the future
> (probably with the limit on cyclic relationships).
> And yes, you can send your request to sqlwish@.microsoft.com. More requests
> they get, better are the chances you will see it in the product at some
> point.
> --
> BG, SQL Server MVP
> www.SolidQualityLearning.com
>
> "Adrian Parker" <apparker@.nospam.nospam> wrote in message
> news:uhp88p1PFHA.3076@.TK2MSFTNGP12.phx.gbl...
>