Complex WHERE Logic

[Tom Slickers]

Back in July I posted a message asking about the implementation of complex
WHERE conditions in MDX. In particular, I was looking for a way to simulate
SQL OR logic. The application is insurance. My cube has a Vehicle Type
dimension (Van, Pickup Truck, etc..) and a Vehicle Use dimension (Business,
Farm, Pleasure, etc.). I need to build the MDX equivalent of the following
(for example):

SELECT ...
FROM ...
WHERE vehicle_type='PICKUP TRUCK' or vehicle_use='FARM'

Chris Webb gave me the following very nice solution:

WITH
CELL CALCULATION [FarmTruck] For '({[Measures].Members})'
AS
'CALCULATIONPASSVALUE(
([Vehicle Use].[FARM]) +
([Vehicle Type].[PICKUP TRUCK]) -
([Vehicle Use].[FARM],[Vehicle Type].[PICKUP TRUCK])
,0)'

SELECT {Measures.Members} etc..

This seems to work fine, but there are two problems:

1. It will be complicated to generalize this to more than two conditions,
e.g., vehicle_type='PICKUP TRUCK' or vehicle_use='FARM' or model_year=2002.
My client has reluctantly agreed that this limitation is acceptable.

2. If I include either Vehicle Use or Vehicle Type on another axis, e.g.,

WITH
CELL CALCULATION [FarmTruck] For '({[Measures].Members})'
AS
'CALCULATIONPASSVALUE(
([Vehicle Use].[FARM]) +
([Vehicle Type].[PICKUP TRUCK]) -
([Vehicle Use].[FARM],[Vehicle Type].[PICKUP TRUCK])
,0)'

SELECT {Measures.Members} ON AXIS(0),
[Vehicle Type].Members ON AXIS(1)
(etc.)

.. the query returns erroneous results. My client is less happy about this.
The only solution I can think of is to create two dimensions for each
existing one (e.g., Vehicle Use 1 and Vehicle Use 2). Each dimension would
have the same members but I would then be able to use one in the cell
calculation and one on AXIS(1). This is not desirable because my cube
already has a lot of dimensions.

Thoughts? Is there another way to do this?

Tom

[Tom Slickers]

This is a follow up to my previous message. I looked more carefully at the
postings from July, and George Spofford had suggested a method based on
NONEMPTYCROSSJOIN that generalizes easily to more than two conditions
(although performanc is a potential problem). Also, I was able to put the
entire expression on AXIS(1), which causes both Vehicle Type and Vehicle Use
to appear there. The only think I can't figure out how to do is to include
just Vehicle Type, or just Vehicle Use, on AXIS(1).

Is there some clever way to do this?

Tom

"Tom Slickers" <tsli...@hotmail.com> wrote in message
news:eNH1dFpWCHA.1912@tkmsftngp09...

[carlos ortiz]

From the "SQL Server Resource Kit":
-----

How Can I Implement a Logical AND or OR Condition in a WHERE Clause?

For SQL users, the use of AND and OR logical operators in the WHERE clause
of a SQL statement is an essential tool for constructing business queries.
However, the WHERE clause of an MDX statement serves a slightly different
purpose, and understanding how the WHERE clause is used in MDX can assist in
constructing such business queries.

The WHERE clause in MDX is used to further restrict the results of an MDX
query, in effect providing another dimension on which the results of the
query are further sliced. As such, only expressions that resolve to a single
tuple are allowed. The WHERE clause implicitly supports a logical AND
operation involving members across different dimensions, by including the
members as part of a tuple. To support logical AND operations involving
members within a single dimensions, as well as logical OR operations, a
calculated member needs to be defined in addition to the use of the WHERE
clause.

For example, the following MDX query illustrates the use of a calculated
member to support a logical OR. The query returns unit sales by quarter and
year for all food and drink related products sold in 1997, run against the
Sales cube in the FoodMart 2000 database.

Code Example 23.6

WITH
MEMBER
[Product].[Food OR Drink]
AS
'([Product].[Food], Measures.[Unit Sales]) + ([Product].[Drink],
Measures.[Unit
Sales])'
SELECT
{Measures.[Unit Sales]}
ON COLUMNS,
DESCENDANTS(Time.[1997], [Quarter], SELF_AND_BEFORE)
ON ROWS
FROM
Sales
WHERE
[Product].[Food OR Drink]

The calculated member simply adds the values of the Unit Sales measure for
the Food and the Drink levels of the Product dimension together. The WHERE
clause is then used to restrict return of information only to the calculated
member, effectively implementing a logical OR to return information for all
time periods that contain unit sales values for either food, drink, or both
types of products.

You can use the Aggregate function in similar situations where all measures
are not aggregated by summing. To return the same results in the above
example using the Aggregate function, replace the definition for the
calculated member with this definition:

'Aggregate({[Product].[Food], [Product].[Drink]})'

A logical AND, by contrast, can be supported by using two different
techniques. If the members used to construct the logical AND reside on
different dimensions, all that is required is a WHERE clause that uses a
tuple representing all involved members. The following MDX query uses a
WHERE clause that effectively restricts the query to retrieve unit sales for
drink products in the USA, shown by quarter and year for 1997.

Code Example 23.7

SELECT
{Measures.[Unit Sales]}
ON COLUMNS,
DESCENDANTS([Time].[1997], [Quarter], SELF_AND_BEFORE)
ON ROWS
FROM
Sales
WHERE
([Product].[Drink], [Store].USA)

The WHERE clause in the previous MDX query effectively provides a logical
AND operator, in which all unit sales for 1997 are returned only for drink
products and only for those sold in stores in the USA.

If the members used to construct the logical AND condition reside on the
same dimension, you can use a calculated member or a named set to filter out
the unwanted members, as demonstrated in the following MDX query.

Code Example 23.8

WITH
SET
[Good AND Pearl Stores]
AS
'FILTER(
Store.Members,
([Product].[Good], Measures.[Unit Sales]) > 0 AND
([Product].[Pearl], Measures.[Unit Sales]) > 0
)'
SELECT
DESCENDANTS([Time].[1997], [Quarter], SELF_AND_BEFORE)
ON COLUMNS,
[Good AND Pearl Stores]
ON ROWS
FROM
Sales

The named set, [Good AND Pearl Stores], restricts the displayed unit sales
totals only to those stores that have sold both Good products and Pearl
products.
---
May be is the answer.

Carlos O.

Tom Slickers escribió en mensaje ...

[Chris Webb [MS]]

Hi Tom,

As far as I can see, the crucial question is: what do you want to see when
you have a dimension included in your OR condition also on a visible axis?
Taking your query of

//Including complex conditional logic equating to vehicle_type='PICKUP
TRUCK' or vehicle_use='FARM'
SELECT {Measures.Members} ON 0,
{[Vehicle Type].[PICKUP TRUCK],[Vehicle Type].[VAN]} ON 1
FROM MYCUBE
In a simple cube, you might get a resultset with one measure on columns, and
two members on rows:
MyMeasure
Pickup Truck <value here>
Van <value here>

You have three options as to what the values would be, in my opinion:

OPTION 1)
-------------
You simply exclude Vehicle Type from the OR condition. In this simple
example, since there's only one OR condition, the end result is equivalent
to putting [Vehicle Use].[Farm] in the WHERE clause. In more complex cases
you'd just remove the condition involving this dimension and leave the other
conditions intact.

OPTION 2)
-------------
Strictly enforce the OR condition so that it overrides the CURRENTMEMBER on
any visible axis. This will result in the same value being displayed for
every measure when a dimension is present in the OR condition and on a
visible axis. Modifying my MDX to do this would result in:

WITH
CELL CALCULATION [FarmTruck] For '({[Measures].Members})'
AS
'CALCULATIONPASSVALUE(

([Vehicle Use].[FARM], [Vehicle Type].[All Vehicle Type]) +
([Vehicle Type].[PICKUP TRUCK], [Vehicle Use].[All Vehicle Use]) -

([Vehicle Use].[FARM],[Vehicle Type].[PICKUP TRUCK])
,0)'

SELECT {Measures.Members} ON 0,
{[Vehicle Type].[PICKUP TRUCK],[Vehicle Type].[VAN]} ON 1
FROM MYCUBE

OPTION 3)
-------------
Allow the CURRENTMEMBER to be used in the calculation. This is what is
happening in the original version of my MDX, but you're getting incorrect
results because it was making an assumption. I'll explain: when you write
the expression

([Vehicle Use].[FARM]) + ([Vehicle Type].[PICKUP TRUCK])

in a calculation, what you actually get are the tuples
([Vehicle Use].[FARM], [Vehicle Type].CURRENTMEMBER) + ([Vehicle
Type].[PICKUP TRUCK], [Vehicle Use].CURRENTMEMBER)
The assumption I was making was that both [Vehicle Type] and [Vehicle Use]
would not be used on a visible axis, so their CURRENTMEMBERs would default
to their All members. However, when they are on a visible axis the
CURRENTMEMBER is not necessarily the All member. On the basis of this
assumption I wrote the expression which dealt with potential double counting
of values, which basically removed the assumed overlap:

([Vehicle Use].[FARM]) + ([Vehicle Type].[PICKUP TRUCK]) - ([Vehicle
Use].[FARM], [Vehicle Type].[PICKUP TRUCK])

But if the CURRENTMEMBERs on the two dimensions aren't the All Members, and
the member in the OR condition are on the same level as the members
displayed on the visible axis, there is no chance of double counting - so
you could modify my original code as follows:

WITH
CELL CALCULATION [FarmTruck] For '({[Measures].Members})'
AS
'CALCULATIONPASSVALUE(

IIF([Vehicle Type].CURRENTMEMBER IS [Vehicle Type].[PICKUP TRUCK],
([Vehicle Type].[PICKUP TRUCK]),

([Vehicle Use].[FARM]) +
([Vehicle Type].[PICKUP TRUCK]) -

IIF([Vehicle Type].CURRENTMEMBER IS [Vehicle Type].[All Vehicle Type], 0,
([Vehicle Use].[FARM],[Vehicle Type].[PICKUP TRUCK]))
),0)'

SELECT {Measures.Members} ON 0,
{[Vehicle Type].[PICKUP TRUCK],[Vehicle Type].[VAN]} ON 1
FROM MYCUBE

But this draws attention to a potential problem that I think I mentioned in
an earlier mail: what happens when the member in the OR condition is on a
different level to the members on the visible axis? Imagine that there is
another level on the Vehicle Type dimension, so that Pickup Truck has two
children, Red Pickup and Blue Pickup. If we displayed these two children on
the visible axis and put their parent in the OR condition, it would be
extremely difficult to write MDX that would eliminate the double-counting,
if it was possible at all.

Overall, I guess you'll have to ask your users what they want. It's all
getting more and more complicated... I don't know about you, but it makes my
head hurt when I think about all this! I would also reiterate what George
and I said in reply to your original posts, that SQL might be a better
option for implementing this sort of logic.

George - I'd be interested in reading your thoughts on this problem too.

HTH,

Chris

--

Chris Webb
Consultant, Microsoft Services Switzerland
(to email: remove 'online.' from the address this was posted with)

Microsoft Services Switzerland and our partners can help you with your
Analysis Services project!

Disclaimer: This posting is provided 'AS IS' with no warranties, and confers
no rights.

"Tom Slickers" <tsli...@hotmail.com> wrote in message

news:#lhNr6pWCHA.2444@tkmsftngp09...

[George Spofford]

Performance in the solution I proposed was absolutely abysmal compared to yours,
Chris.

This is a type of query that AS2K and MDX isn't well suited for: a request
that's simple to state in English (and French and Portuguese and SQL, probably
also easy in Farsi but I don't speak it) that has two complex formulations in
MDX. One formulation is quite difficult to make, but performs sort of OK to me
on my hardware. The other is conceptually less difficult but still pretty
awkward, and it performs pretty badly on my hardware and everyone else's.

Tom: Let me ask the question that isn't painful because this is a technical
forum, not an emotional forum: Did these queries run faster in SQL? Did they
seem easier to create?

"Chris Webb [MS]" wrote:

> Hi Tom,
>
> As far as I can see, the crucial question is: what do you want to see when
> you have a dimension included in your OR condition also on a visible axis?
> Taking your query of
>
> //Including complex conditional logic equating to vehicle_type='PICKUP
> TRUCK' or vehicle_use='FARM'
> SELECT {Measures.Members} ON 0,
> {[Vehicle Type].[PICKUP TRUCK],[Vehicle Type].[VAN]} ON 1
> FROM MYCUBE
> In a simple cube, you might get a resultset with one measure on columns, and
> two members on rows:
> MyMeasure

> Pickup Truck ?value here?
> Van ?value here?

> "Tom Slickers" ?tsli...@hotmail.com? wrote in message
> news:#lhNr6pWCHA.2444@tkmsftngp09...
> ? This is a follow up to my previous message. I looked more carefully at the
> ? postings from July, and George Spofford had suggested a method based on
> ? NONEMPTYCROSSJOIN that generalizes easily to more than two conditions
> ? (although performanc is a potential problem). Also, I was able to put the
> ? entire expression on AXIS(1), which causes both Vehicle Type and Vehicle
> Use
> ? to appear there. The only think I can't figure out how to do is to include
> ? just Vehicle Type, or just Vehicle Use, on AXIS(1).
> ?
> ? Is there some clever way to do this?
> ?
> ? Tom
> ?
> ? "Tom Slickers" ?tsli...@hotmail.com? wrote in message
> ? news:eNH1dFpWCHA.1912@tkmsftngp09...
> ? ? Back in July I posted a message asking about the implementation of
> complex
> ? ? WHERE conditions in MDX. In particular, I was looking for a way to
> ? simulate
> ? ? SQL OR logic. The application is insurance. My cube has a Vehicle Type
> ? ? dimension (Van, Pickup Truck, etc..) and a Vehicle Use dimension
> ? (Business,
> ? ? Farm, Pleasure, etc.). I need to build the MDX equivalent of the
> following
> ? ? (for example):
> ? ?
> ? ? SELECT ...
> ? ? FROM ...
> ? ? WHERE vehicle_type='PICKUP TRUCK' or vehicle_use='FARM'
> ? ?
> ? ? Chris Webb gave me the following very nice solution:
> ? ?
> ? ? WITH
> ? ? CELL CALCULATION [FarmTruck] For '({[Measures].Members})'
> ? ? AS
> ? ? 'CALCULATIONPASSVALUE(
> ? ? ([Vehicle Use].[FARM]) +
> ? ? ([Vehicle Type].[PICKUP TRUCK]) -
> ? ? ([Vehicle Use].[FARM],[Vehicle Type].[PICKUP TRUCK])
> ? ? ,0)'
> ? ?
> ? ? SELECT {Measures.Members} etc..
> ? ?
> ? ? This seems to work fine, but there are two problems:
> ? ?
> ? ? 1. It will be complicated to generalize this to more than two
> conditions,
> ? ? e.g., vehicle_type='PICKUP TRUCK' or vehicle_use='FARM' or
> ? model_year=2002.
> ? ? My client has reluctantly agreed that this limitation is acceptable.
> ? ?
> ? ? 2. If I include either Vehicle Use or Vehicle Type on another axis,
> e.g.,
> ? ?
> ? ? WITH
> ? ? CELL CALCULATION [FarmTruck] For '({[Measures].Members})'
> ? ? AS
> ? ? 'CALCULATIONPASSVALUE(
> ? ? ([Vehicle Use].[FARM]) +
> ? ? ([Vehicle Type].[PICKUP TRUCK]) -
> ? ? ([Vehicle Use].[FARM],[Vehicle Type].[PICKUP TRUCK])
> ? ? ,0)'
> ? ?
> ? ? SELECT {Measures.Members} ON AXIS(0),
> ? ? [Vehicle Type].Members ON AXIS(1)
> ? ? (etc.)
> ? ?
> ? ? .. the query returns erroneous results. My client is less happy about
> ? this.
> ? ? The only solution I can think of is to create two dimensions for each
> ? ? existing one (e.g., Vehicle Use 1 and Vehicle Use 2). Each dimension
> would
> ? ? have the same members but I would then be able to use one in the cell
> ? ? calculation and one on AXIS(1). This is not desirable because my cube
> ? ? already has a lot of dimensions.
> ? ?
> ? ? Thoughts? Is there another way to do this?
> ? ?
> ? ? Tom
> ? ?
> ? ?
> ? ?
> ? ?
> ? ?
> ?
> ?

--
George Spofford
Microsoft MVP
Chief Architect / OLAP Solution Provider
DSS Lab
http://www.dsslab.com
geo...@dsslab.com
ISVs ? IT organizations: Find out how DSS Lab can speed your development!

[Tom Slickers]

Chris, once again I would like to thank you for your detailed and thougthful
response to my question. However, I am perplexed by your suggestion that
there are three possible correct answers. Suppose the cube is based on a
fact table with just four rows:

Vehicle Type, Vehicle Use, Premium
PICKUP TRUCK,FARM,1000
PICKUP TRUCK,PERSONAL,2000
VAN,FARM,2500
VAN,PERSONAL,4500

Then (in SQL):

SELECT vehicle_type,sum(premium)
from table
where vehicle_type='PICKUP TRUCK' or vehicle_use='FARM'
group by vehicle_type

results in a well-defined result of:

PICKUP TRUCK,3000
VAN,2500

Similarly,

SELECT vehicle_use,sum(premium)
from table
where vehicle_type='PICKUP TRUCK' or vehicle_use='FARM'
group by vehicle_use

gives:

FARM,3500
PERSONAL,2000

I tried your three solutions, and none of these give these results.

George, I agree that SQL is a better way to express this. The application is
currently running on Oracle (on big UNIX boxes) and we have all of the SQL
generation details worked out. The problem is performance. We have fact
tables with over 300 million rows. Partitioning by state helps, but there
are individual states with over 25 million rows. Query performance is
terrible as you can imagine. We tried creating aggregations within the
relational database, but the aggregations take too long to create and are
not flexible enough to improve performance on enough user queries. That's
why we are looking at MSAS. Your last posting suggests that you have working
solutions. If so, would you mind posting them? If they are as complex as you
sugggest we may decide not to implement them, but I would like to take a
look any way.

If this can't be done, it can't be done. I just need to set expectations
with my client. They are excited enough about the performance improvements
they will get from MSAS that they are willing to give up some flexibility.

Thanks again.

Tom

"George Spofford" <geo...@dsslab.com> wrote in message
news:3D81DE35...@dsslab.com...

[Chris Webb [MS]]

Tom,

Sorry none of my solutions did what you wanted but on this one I agree with
George: some things which are easy to express in SQL turn into absolute
nightmares in MDX. And this is one such nightmare. I'll have a think about a
new version of the MDX over the weekend, but at the moment I'm afraid that
if I spent any more time on this my brain would overheat.

I'm sure it would be much easier to adapt George's approach to work with
members on a visible axis, but as he says, performance would still be poor.
In fact, with the sort of volumes you're talking about I'm sure performance
on even the most optimised MDX would still be poor; and on top of that, the
code would be extremely complex and therefore very difficult to maintain.

Of course, if you didn't have a requirement for this sort of OR logic then
you could build a very fast-performing OLAP solution. Is there a convincing
business reason to have it? Or would your customers be happy with an OLAP
solution that only does traditional slice 'n' dicing, but does it very
quickly and allows ad-hoc querying as well as many forms of analysis which
were previously impossible?

Regards,

Chris

--

Chris Webb
Consultant, Microsoft Services Switzerland
(to email: remove 'online.' from the address this was posted with)

Microsoft Services Switzerland and our partners can help you with your
Analysis Services project!

Disclaimer: This posting is provided 'AS IS' with no warranties, and confers
no rights.

"Tom Slickers" <tsli...@hotmail.com> wrote in message
news:#SiUdVyWCHA.2404@tkmsftngp10...

[Tom Slickers]

Chris, to answer your questions, there is a convincing business reason to
have this type of logic. However, my client will still be able to query the
existing (Oracle) database using SQL when necessary.

My client recognizes that it may not be possible to design a system where
every possible query runs quickly. For cases like the one in question, he
would settle for a query that takes a long time, rather than not being able
to run the query at all. SQL query performance is so bad that I believe even
relatively slow MDX will be better.

Tom

"Chris Webb [MS]" <chw...@online.microsoft.com> wrote in message
news:O3ejkozWCHA.1792@tkmsftngp12...

[George Spofford]

Tom, Chris,

It's not obvious to me. Chris, you added what needed to be to pick out the
visible axis. Tom, I'd be very interested to hear how this performs relative to
SQL. Properly indexed for queries like this, Oracle ought to be reasonably fast.

"Chris Webb [MS]" wrote:

> Hi Tom,
>
> Well, I'm afraid that the task of trying to adapt my MDX to your
> requirements has completely defeated me. There probably is a solution but it
> would take me a long, long time to get there...
>
> However, I've managed to get George's approach to do what you want to do.
> All it involves is another layer of filtering after you've done the
> NONEMPTYCROSSJOINs, so that you only retrieve the tuples which contain the
> CURRENTMEMBER on your visible dimension. I've attached the small Access db
> and cube that I've used to test this; in this example, the sample SQL query
>
> SELECT vehicle_type,sum(premium)
> from table
> where vehicle_type='PICKUP TRUCK' or vehicle_use='FARM' or owner_gender='M'
> group by vehicle_type
>
> now becomes:
>
> WITH MEMBER MEASURES.TEST AS '
> SUM(
> GENERATE(
> UNIQUE(
> NONEMPTYCROSSJOIN({[Vehicle Type].[Vehicle Type].MEMBERS + {{{[Vehicle
> Type].CURRENTMEMBER} AS SEL_VTYPE} - SEL_VTYPE}}, {[Vehicle Use].[All
> Vehicle Use].[Farm]}, {[Gender].[Owner Gender].MEMBERS})
> +
> NONEMPTYCROSSJOIN({[Vehicle Type].[All Vehicle Type].[Pickup]}, {[Vehicle
> Use].[Vehicle Use].MEMBERS}, {[Gender].[Owner Gender].MEMBERS})
> +
> NONEMPTYCROSSJOIN({[Vehicle Type].[Vehicle Type].MEMBERS}, {[Vehicle
> Use].[Vehicle Use].MEMBERS}, {[Gender].[All Gender].[M]})
> ) AS INNERSET
> ,FILTER({INNERSET.CURRENT}, [Vehicle Type].CURRENTMEMBER IS
> SEL_VTYPE.ITEM(0)))
> ,MEASURES.PREMIUM)'
> SELECT
> {MEASURES.TEST} ON 0,
> [Vehicle Type].[Vehicle Type].MEMBERS
> ON 1
> FROM DEMO
>
> Unpleasant, isn't it? After we've created the set of tuples defined by the
> OR conditions in the same way as in George's example, we then filter out
> those which don't contain the CURRENTMEMBER on Vehicle Type. However, to do
> this we need to use GENERATE - and this in turn overrides the value of
> [Vehicle Type].CURRENTMEMBER. So what I do is cunningly define a named set
> called SEL_VTYPE which contains only the CURRENTMEMBER from the query axis,
> and then we can compare this with the CURRENTMEMBER we get from the GENERATE
> when we're iterating over the tuples.
>
> I'm certain there's an easier way of doing it, but it eludes me for the
> moment.... George, can you see it? I'll bet it's obvious.

>
> HTH,
>
> Chris
>
> --
>
> Chris Webb
> Consultant, Microsoft Services Switzerland
> (to email: remove 'online.' from the address this was posted with)
>
> Microsoft Services Switzerland and our partners can help you with your
> Analysis Services project!
>
> Disclaimer: This posting is provided 'AS IS' with no warranties, and confers
> no rights.
>

> "Tom Slickers" <tsli...@hotmail.com> wrote in message

> news:unYWp3zWCHA.2520@tkmsftngp09...

> Name: wheredemo.zip
> wheredemo.zip Type: Zip Compressed Data (application/x-zip-compressed)
> Encoding: x-uuencode

--
George Spofford
Microsoft MVP
Chief Architect / OLAP Solution Provider
DSS Lab
http://www.dsslab.com
geo...@dsslab.com

ISVs & IT organizations: Find out how DSS Lab can speed your development!

[Tom Slickers]

George, Chris:

Chris's solution is working well, although writing VB code to generate the
correct MDX for all of the cases we have to consider will be a challenge.
Query performance is much better than we can get from Oracle, apparently due
to the MSAS aggregations.

My experience is that OLAP query performance in a relational database is
driven by two factors:

1. How fast the database engine can find the rows to be included. This can
be improved by proper indexing.

2. How fast the database engine can sum the rows once it has found them. If
there are a lot of rows to sum, it is going to take a long time. In our
application, if the user picks Vehicle Type=CAR or Vehicle Use=PLEASURE, the
database engine may have to sum millions of rows. The only way to improve
this is by creating aggregations within the relational database. We found
that this was not a good approach because a) it took too long to create the
aggregations, b) because of a), we were restricted in the number of
aggregations we could create, and c) as we added aggregations we had to keep
modifying our client application.

Thanks to both of you for your help.

Tom

"George Spofford" <geo...@dsslab.com> wrote in message

news:3D8A0273...@dsslab.com...