Gene,
Not to beat a dead horse.... While I think these may have been mentioned in various places....
1) It used to be that a Select statement would be optimized by VFP to open the source table again, in another work area, and then set a filter on it. This was a problem when people thought they had a cursor and updated the contents, only to find out they had edited the actual data. So they added a "nofilter" clause that forced VFP to create a new cursor and not use the original approach.
2) I haven't seen any discussion on set relation - which might also do what you want (but I haven't actually tested it so may be wrong.)
3) You can use the browse for .... command (I tended to use this over set filter, especially since I could then use "browse last" as well.) As I recall, this worked the same as set filter but didn't require the literal values that set filter do.
4) Of course, Select is an option - but then you may have to guess if VFP did #1 or if it actually created a cursor and your edits are thrown away when you close it.
5) I can't remember, but did set filter allow you to reference a variable? And, if so, did changing that variable then change the effect of the filter? If so, this might also be an option.
Take care,
Fletcher
Fletcher Johnson FletcherSJohnson@Yahoo.com LinkedIn.com/in/FletcherJohnson twitter.com/fletcherJ strava.com/athletes/fletcherjohnson 408-946-0960 - work 408-781-2345 - cell
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Gene Wirchenko Sent: Tuesday, May 14, 2019 3:46 PM To: ProFox Email List Subject: Filtering Oddity
Hello:
I was looking over a program preparatory to an enhancement. I inserted a debugging browse statement in a branch that I was going to add some error reporting to. The branch, oddly, did not get executed. Dig, dig ...
use cwkf set filter to validto>={^2019.01.01} count browse
Lots of rows. Oh, the filter needs to be extended.
set filter to filter()+" and empty(wfccccd)"
VFP: Nice try. (Actually, "Command contains unrecognized phrase/keyword."
set filter to (filter()+" and empty(wfccccd)")
VFP: Don't be silly. (Same error.)
Putting an avaluate() around it does not work either. ("Syntax error.")
I do know that I can do f=filter()+" and empty(wfccccd)" set filter to &f but in the heat of debugging, I would prefer just one statement.
Is there a way to extend a filter in one statement without retyping the current filter expression?
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]
On Sat, May 18, 2019 at 12:01 AM Fletcher Johnson FletcherSJohnson@yahoo.com wrote:
- It used to be that a Select statement would be optimized by VFP to open
the source table again, in another work area, and then set a filter on it. This was a problem when people thought they had a cursor and updated the contents, only to find out they had edited the actual data. So they added a "nofilter" clause that forced VFP to create a new cursor and not use the original approach.
Had to be bad coding, possibly mixing up aliases in the process.
- I can't remember, but did set filter allow you to reference a variable?
And, if so, did changing that variable then change the effect of the filter? If so, this might also be an option.
SET FILTER can use variables. Changing the values of the variables should not affect executed SET FILTER if I remember correctly.
Not sure where the "Had to be bad coding" comes in.
For example, if you did "select * from employee where last name = 'Smith'" you would get a cursor of only those employees. The employee table would still be open, but VFP opened it again, in a different work area, with a different alias, and then put a set filter. Edits to this cursor would be written to the actual source table.
Originally, we would add a calculated field which then forced VFP to create a truly new cursor. So we might do something like "select employee.*, date() as somedate from employee where last name = 'Smith'". Finally, MS added the nofilter clause that we could use instead. This insured that when we used Select, we always had a new cursor and could edit it as we desired without affecting the source table.
Fletcher
Fletcher Johnson FletcherSJohnson@Yahoo.com LinkedIn.com/in/FletcherJohnson twitter.com/fletcherJ strava.com/athletes/fletcherjohnson 408-946-0960 - work 408-781-2345 - cell
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Man-wai Chang Sent: Sunday, May 19, 2019 9:42 PM To: ProFox Email List Subject: Re: Filtering Oddity
On Sat, May 18, 2019 at 12:01 AM Fletcher Johnson FletcherSJohnson@yahoo.com wrote:
- It used to be that a Select statement would be optimized by VFP to open
the source table again, in another work area, and then set a filter on it. This was a problem when people thought they had a cursor and updated the contents, only to find out they had edited the actual data. So they added
a
"nofilter" clause that forced VFP to create a new cursor and not use the original approach.
Had to be bad coding, possibly mixing up aliases in the process.
- I can't remember, but did set filter allow you to reference a variable?
And, if so, did changing that variable then change the effect of the
filter?
If so, this might also be an option.
SET FILTER can use variables. Changing the values of the variables should not affect executed SET FILTER if I remember correctly.
On 20/05/2019 19:39, Fletcher Johnson wrote:
Not sure where the "Had to be bad coding" comes in.
For example, if you did "select * from employee where last name = 'Smith'" you would get a cursor of only those employees. The employee table would still be open, but VFP opened it again, in a different work area, with a different alias, and then put a set filter. Edits to this cursor would be written to the actual source table.
Are you sure about that? Never heard of that behaviour before. If I do a "Select * from picorder where vt_desc = 'India' into cursor mycursor" I get a standalone cursor that I can't update (DBF() = C:\TEMP\0000FABT02AV.TMP) If I do a "Select * from picorder where vt_desc = 'India' into cursor mycursor READWRITE" I still get a stand alone cursor that can be updated but won't affect the source table. If I leave off the into cursor mycursor then I still get a stand alone cursor called query.
I don't know if that behaviour was from an older VFP version but I don't remember it. Am I getting Alzheimer's? Somebody put me out of my misery :-)
Peter
This communication is intended for the person or organisation to whom it is addressed. The contents are confidential and may be protected in law. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email.
www.whisperingsmith.com
Whispering Smith Ltd Head Office:61 Great Ducie Street, Manchester M3 1RR. Tel:0161 831 3700 Fax:0161 831 3715
London Office: 101 St. Martin's Lane,London, WC2N 4AZ Tel:0207 299 7960
I don't know if that behaviour was from an older VFP version but I don't remember it. Am I getting Alzheimer's? Somebody put me out of my misery :-)
Since VFP6 if you do a select that involves one table and is 100% optimisable, it will just show you the actual table with a behind-the-scenes filter set. If you add the NOFILTER clause to the SELECT, it will always create a temporary table with the results.
VFP's query engine decides what has less overhead; running the query or doing a USE...AGAIN with a filter. NOFILTER and READWRITE force VFP to create a temp file with the results.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Peter Cushing Sent: Tuesday, May 21, 2019 6:35 AM To: profoxtech@leafe.com Subject: Re: Filtering Oddity
On 20/05/2019 19:39, Fletcher Johnson wrote:
Not sure where the "Had to be bad coding" comes in.
For example, if you did "select * from employee where last name = 'Smith'" you would get a cursor of only those employees. The employee table would still be open, but VFP opened it again, in a different work area, with a different alias, and then put a set filter. Edits to this cursor would be written to the actual source table.
Are you sure about that? Never heard of that behaviour before. If I do a "Select * from picorder where vt_desc = 'India' into cursor mycursor" I get a standalone cursor that I can't update (DBF() = C:\TEMP\0000FABT02AV.TMP) If I do a "Select * from picorder where vt_desc = 'India' into cursor mycursor READWRITE" I still get a stand alone cursor that can be updated but won't affect the source table. If I leave off the into cursor mycursor then I still get a stand alone cursor called query.
I don't know if that behaviour was from an older VFP version but I don't remember it. Am I getting Alzheimer's? Somebody put me out of my misery :-)
Peter
This communication is intended for the person or organisation to whom it is addressed. The contents are confidential and may be protected in law. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email.
www.whisperingsmith.com
Whispering Smith Ltd Head Office:61 Great Ducie Street, Manchester M3 1RR. Tel:0161 831 3700 Fax:0161 831 3715
London Office: 101 St. Martin's Lane,London, WC2N 4AZ Tel:0207 299 7960
_______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/220dcea1-730f-f7ac-6340-d2846c84d3af@whispe... ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious. Report [OT] Abuse: http://leafe.com/reportAbuse/220dcea1-730f-f7ac-6340-d2846c84d3af@whispering...
So if you leave off the NOFILTER/READWRITE you have a read only file, so "edits to this cursor would be written to the actual source table" would not apply. It sounds like there are no circumstances where you could write data back from the select statement, or am I missing something?
Peter
On 21/05/2019 12:59, Richard Kaye wrote:
VFP's query engine decides what has less overhead; running the query or doing a USE...AGAIN with a filter. NOFILTER and READWRITE force VFP to create a temp file with the results.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Peter Cushing Sent: Tuesday, May 21, 2019 6:35 AM To: profoxtech@leafe.com Subject: Re: Filtering Oddity
On 20/05/2019 19:39, Fletcher Johnson wrote:
Not sure where the "Had to be bad coding" comes in.
For example, if you did "select * from employee where last name = 'Smith'" you would get a cursor of only those employees. The employee table would still be open, but VFP opened it again, in a different work area, with a different alias, and then put a set filter. Edits to this cursor would be written to the actual source table.
Are you sure about that? Never heard of that behaviour before. If I do a "Select * from picorder where vt_desc = 'India' into cursor mycursor" I get a standalone cursor that I can't update (DBF() = C:\TEMP\0000FABT02AV.TMP) If I do a "Select * from picorder where vt_desc = 'India' into cursor mycursor READWRITE" I still get a stand alone cursor that can be updated but won't affect the source table. If I leave off the into cursor mycursor then I still get a stand alone cursor called query.
I don't know if that behaviour was from an older VFP version but I don't remember it. Am I getting Alzheimer's? Somebody put me out of my misery :-)
Peter
This communication is intended for the person or organisation to whom it is addressed. The contents are confidential and may be protected in law. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email.
www.whisperingsmith.com
Whispering Smith Ltd Head Office:61 Great Ducie Street, Manchester M3 1RR. Tel:0161 831 3700 Fax:0161 831 3715
London Office: 101 St. Martin's Lane,London, WC2N 4AZ Tel:0207 299 7960
[excessive quoting removed by server]
The comment about edits doesn't seem right to me. I was just mentioning that VFP could potentially do a USE...AGAIN with a filter if you don't use either the NOFILTER (read-only) or READWRITE keywords when the destination is a cursor. Tamar's Taming SQL book has a good explanation of what VFP does starting on page 91. There's probably some useful commentary in HG and FoxWiki as well.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Peter Cushing Sent: Tuesday, May 21, 2019 8:13 AM To: profoxtech@leafe.com Subject: Re: Filtering Oddity
So if you leave off the NOFILTER/READWRITE you have a read only file, so "edits to this cursor would be written to the actual source table" would not apply. It sounds like there are no circumstances where you could write data back from the select statement, or am I missing something?
Peter
On 21/05/2019 12:59, Richard Kaye wrote:
VFP's query engine decides what has less overhead; running the query or doing a USE...AGAIN with a filter. NOFILTER and READWRITE force VFP to create a temp file with the results.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Peter Cushing Sent: Tuesday, May 21, 2019 6:35 AM To: profoxtech@leafe.com Subject: Re: Filtering Oddity
On 20/05/2019 19:39, Fletcher Johnson wrote:
Not sure where the "Had to be bad coding" comes in.
For example, if you did "select * from employee where last name = 'Smith'" you would get a cursor of only those employees. The employee table would still be open, but VFP opened it again, in a different work area, with a different alias, and then put a set filter. Edits to this cursor would be written to the actual source table.
Are you sure about that? Never heard of that behaviour before. If I do a "Select * from picorder where vt_desc = 'India' into cursor mycursor" I get a standalone cursor that I can't update (DBF() = C:\TEMP\0000FABT02AV.TMP) If I do a "Select * from picorder where vt_desc = 'India' into cursor mycursor READWRITE" I still get a stand alone cursor that can be updated but won't affect the source table. If I leave off the into cursor mycursor then I still get a stand alone cursor called query.
I don't know if that behaviour was from an older VFP version but I don't remember it. Am I getting Alzheimer's? Somebody put me out of my misery :-)
Peter
This communication is intended for the person or organisation to whom it is addressed. The contents are confidential and may be protected in law. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email.
www.whisperingsmith.com
Whispering Smith Ltd Head Office:61 Great Ducie Street, Manchester M3 1RR. Tel:0161 831 3700 Fax:0161 831 3715
London Office: 101 St. Martin's Lane,London, WC2N 4AZ Tel:0207 299 7960
[excessive quoting removed by server]
_______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: https://leafe.com/archives This message: https://leafe.com/archives/byMID/22c7d3b8-1933-ffc2-c93e-43f7964d1cfd@whispe... ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious. Report [OT] Abuse: http://leafe.com/reportAbuse/22c7d3b8-1933-ffc2-c93e-43f7964d1cfd@whispering...
Peter,
It's been a while.... But I do know that this became a big issue when people found out that changes to what they thought was a temporary table/cursor were being made back to the actual table. I was able to demonstrate this in a session I gave at one of the Devcons.
The addition of the NoFilter clause was made specifically to overcome this issue.
In any case, my original point was that I wasn't sure who was being accused of "bad coding" - MS or someone else.
I never really used the set filter - I always used "browse for ...." (when I did want to edit in the table directly) or Select.... (using noFilter only when I wanted to be able to edit the resulting cursor without updating the source table.) Even better, "Browse For ... " gave me flexibility that Set Filter did not and could be done in one line (which is what I believe was the objective of the original post.) Not to mention how great "Browse last" was as well.
Anyway, I think this dead horse is suitably beaten (sorry PETA).... :)
Fletcher
Fletcher Johnson FletcherSJohnson@Yahoo.com LinkedIn.com/in/FletcherJohnson twitter.com/fletcherJ strava.com/athletes/fletcherjohnson 408-946-0960 - work 408-781-2345 - cell
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Peter Cushing Sent: Tuesday, May 21, 2019 5:13 AM To: profox@leafe.com Subject: Re: Filtering Oddity
So if you leave off the NOFILTER/READWRITE you have a read only file, so "edits to this cursor would be written to the actual source table" would not apply. It sounds like there are no circumstances where you could write data back from the select statement, or am I missing something?
Peter
On 21/05/2019 12:59, Richard Kaye wrote:
VFP's query engine decides what has less overhead; running the query or doing a USE...AGAIN with a filter. NOFILTER and READWRITE force VFP to create a temp file with the results.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Peter Cushing Sent: Tuesday, May 21, 2019 6:35 AM To: profoxtech@leafe.com Subject: Re: Filtering Oddity
On 20/05/2019 19:39, Fletcher Johnson wrote:
Not sure where the "Had to be bad coding" comes in.
For example, if you did "select * from employee where last name = 'Smith'" you would get a cursor of only those employees. The employee table would still be open, but VFP opened it again, in a different work area, with a different alias, and then put a set filter. Edits to this cursor would be written to the actual source table.
Are you sure about that? Never heard of that behaviour before. If I do a "Select * from picorder where vt_desc = 'India' into cursor mycursor" I get a standalone cursor that I can't update (DBF() = C:\TEMP\0000FABT02AV.TMP) If I do a "Select * from picorder where vt_desc = 'India' into cursor mycursor READWRITE" I still get a stand alone cursor that can be updated but won't affect the source table. If I leave off the into cursor mycursor then I still get a stand alone cursor called query.
I don't know if that behaviour was from an older VFP version but I don't remember it. Am I getting Alzheimer's? Somebody put me out of my misery :-)
Peter
This communication is intended for the person or organisation to whom it is addressed. The contents are confidential and may be protected in law. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email.
www.whisperingsmith.com
Whispering Smith Ltd Head Office:61 Great Ducie Street, Manchester M3 1RR. Tel:0161 831 3700 Fax:0161 831 3715
London Office: 101 St. Martin's Lane,London, WC2N 4AZ Tel:0207 299 7960
[excessive quoting removed by server]
Anyway, I think this dead horse is suitably beaten (sorry PETA).... :)
<<
Not quite. I haven't had a chance to chime in yet.
.....
Ok...now the horse is truly dead. :)
Paul H. Tarver
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Fletcher Johnson Sent: Wednesday, May 22, 2019 10:30 AM To: profoxtech@leafe.com Subject: RE: Filtering Oddity
Peter,
It's been a while.... But I do know that this became a big issue when people found out that changes to what they thought was a temporary table/cursor were being made back to the actual table. I was able to demonstrate this in a session I gave at one of the Devcons.
The addition of the NoFilter clause was made specifically to overcome this issue.
In any case, my original point was that I wasn't sure who was being accused of "bad coding" - MS or someone else.
I never really used the set filter - I always used "browse for ...." (when I did want to edit in the table directly) or Select.... (using noFilter only when I wanted to be able to edit the resulting cursor without updating the source table.) Even better, "Browse For ... " gave me flexibility that Set Filter did not and could be done in one line (which is what I believe was the objective of the original post.) Not to mention how great "Browse last" was as well.
Anyway, I think this dead horse is suitably beaten (sorry PETA).... :)
Fletcher
Fletcher Johnson FletcherSJohnson@Yahoo.com LinkedIn.com/in/FletcherJohnson twitter.com/fletcherJ strava.com/athletes/fletcherjohnson 408-946-0960 - work 408-781-2345 - cell
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Peter Cushing Sent: Tuesday, May 21, 2019 5:13 AM To: profox@leafe.com Subject: Re: Filtering Oddity
So if you leave off the NOFILTER/READWRITE you have a read only file, so "edits to this cursor would be written to the actual source table" would not apply. It sounds like there are no circumstances where you could write data back from the select statement, or am I missing something?
Peter
On 21/05/2019 12:59, Richard Kaye wrote:
VFP's query engine decides what has less overhead; running the query or
doing a USE...AGAIN with a filter. NOFILTER and READWRITE force VFP to create a temp file with the results.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Peter Cushing Sent: Tuesday, May 21, 2019 6:35 AM To: profoxtech@leafe.com Subject: Re: Filtering Oddity
On 20/05/2019 19:39, Fletcher Johnson wrote:
Not sure where the "Had to be bad coding" comes in.
For example, if you did "select * from employee where last name =
'Smith'"
you would get a cursor of only those employees. The employee table would still be open, but VFP opened it again, in a different work area, with a different alias, and then put a set filter. Edits to this cursor would be written to the actual source table.
Are you sure about that? Never heard of that behaviour before. If I do a "Select * from picorder where vt_desc = 'India' into cursor
mycursor" I get a standalone cursor that I can't update (DBF() =
C:\TEMP\0000FABT02AV.TMP) If I do a "Select * from picorder where vt_desc = 'India' into cursor
mycursor READWRITE" I still get a stand alone cursor that can be updated but won't affect the source table.
If I leave off the into cursor mycursor then I still get a stand alone
cursor called query.
I don't know if that behaviour was from an older VFP version but I don't
remember it. Am I getting Alzheimer's? Somebody put me out of my misery :-)
Peter
This communication is intended for the person or organisation to whom it
is addressed. The contents are confidential and may be protected in law. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email.
www.whisperingsmith.com
Whispering Smith Ltd Head Office:61 Great Ducie Street, Manchester M3 1RR.
Tel:0161 831 3700 Fax:0161 831 3715
London Office: 101 St. Martin's Lane,London, WC2N 4AZ Tel:0207 299 7960
[excessive quoting removed by server]
Warning!
browse last restores only the appearance!
Gianni
On Wed, 22 May 2019 08:29:31 -0700, "Fletcher Johnson" FletcherSJohnson@yahoo.com wrote:
Peter,
It's been a while.... But I do know that this became a big issue when people found out that changes to what they thought was a temporary table/cursor were being made back to the actual table. I was able to demonstrate this in a session I gave at one of the Devcons.
The addition of the NoFilter clause was made specifically to overcome this issue.
In any case, my original point was that I wasn't sure who was being accused of "bad coding" - MS or someone else.
I never really used the set filter - I always used "browse for ...." (when I did want to edit in the table directly) or Select.... (using noFilter only when I wanted to be able to edit the resulting cursor without updating the source table.) Even better, "Browse For ... " gave me flexibility that Set Filter did not and could be done in one line (which is what I believe was the objective of the original post.) Not to mention how great "Browse last" was as well.
Anyway, I think this dead horse is suitably beaten (sorry PETA).... :)
Fletcher
Fletcher Johnson FletcherSJohnson@Yahoo.com LinkedIn.com/in/FletcherJohnson twitter.com/fletcherJ strava.com/athletes/fletcherjohnson 408-946-0960 - work 408-781-2345 - cell
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Peter Cushing Sent: Tuesday, May 21, 2019 5:13 AM To: profox@leafe.com Subject: Re: Filtering Oddity
So if you leave off the NOFILTER/READWRITE you have a read only file, so "edits to this cursor would be written to the actual source table" would not apply. It sounds like there are no circumstances where you could write data back from the select statement, or am I missing something?
Peter
On 21/05/2019 12:59, Richard Kaye wrote:
VFP's query engine decides what has less overhead; running the query or doing a USE...AGAIN with a filter. NOFILTER and READWRITE force VFP to create a temp file with the results.
--
rk
-----Original Message----- From: ProfoxTech profoxtech-bounces@leafe.com On Behalf Of Peter Cushing Sent: Tuesday, May 21, 2019 6:35 AM To: profoxtech@leafe.com Subject: Re: Filtering Oddity
On 20/05/2019 19:39, Fletcher Johnson wrote:
Not sure where the "Had to be bad coding" comes in.
For example, if you did "select * from employee where last name = 'Smith'" you would get a cursor of only those employees. The employee table would still be open, but VFP opened it again, in a different work area, with a different alias, and then put a set filter. Edits to this cursor would be written to the actual source table.
Are you sure about that? Never heard of that behaviour before. If I do a "Select * from picorder where vt_desc = 'India' into cursor mycursor" I get a standalone cursor that I can't update (DBF() = C:\TEMP\0000FABT02AV.TMP) If I do a "Select * from picorder where vt_desc = 'India' into cursor mycursor READWRITE" I still get a stand alone cursor that can be updated but won't affect the source table. If I leave off the into cursor mycursor then I still get a stand alone cursor called query.
I don't know if that behaviour was from an older VFP version but I don't remember it. Am I getting Alzheimer's? Somebody put me out of my misery :-)
Peter
This communication is intended for the person or organisation to whom it is addressed. The contents are confidential and may be protected in law. Unauthorised use, copying or disclosure of any of it may be unlawful. If you have received this message in error, please notify us immediately by telephone or email.
www.whisperingsmith.com
Whispering Smith Ltd Head Office:61 Great Ducie Street, Manchester M3 1RR. Tel:0161 831 3700 Fax:0161 831 3715
London Office: 101 St. Martin's Lane,London, WC2N 4AZ Tel:0207 299 7960
[excessive quoting removed by server]
-
Alan Bourke -
Fletcher Johnson -
Gianni Turri -
Man-wai Chang -
Paul H. Tarver -
Peter Cushing -
Richard Kaye