"The expression you entered is too complex"

[njgreen2001]

I thought the length of this might give me problems. Any suggestions
on how to shorten it?

Expression:

=IIf([Text111]="A Pos" And [Text168]="A
Pos",(DLookUp("[AP/AP]","[qCompatibility]")), IIf([Text111]="A Pos" And
[Text168]="A Neg",(DLookUp("[AP/AN]","[qCompatibility]")),
IIf([Text111]="A Pos" And [Text168]="B
Pos",(DLookUp("[AP/BP]","[qCompatibility]")), IIf([Text111]="A Pos" And
[Text168]="B Neg",(DLookUp("[AP/BN]","[qCompatibility]")),
IIf([Text111]="A Pos" And [Text168]="O
Pos",(DLookUp("[AP/OP]","[qCompatibility]")), IIf([Text111]="A Pos" And
[Text168]="O Neg",(DLookUp("[AP/ON]","[qCompatibility]")),
IIf([Text111]="A Pos" And [Text168]="AB
Pos",(DLookUp("[AP/ABP]","[qCompatibility]")), IIf([Text111]="A Pos"
And [Text168]="AB Neg",(DLookUp("[AP/ABN]","[qCompatibility]")),

IIf([Text111]="A Neg" And [Text168]="A
Pos",(DLookUp("[AN/AP]","[qCompatibility]")), IIf([Text111]="A Neg" And
[Text168]="A Neg",(DLookUp("[AN/AN]","[qCompatibility]")),
IIf([Text111]="A Neg" And [Text168]="B
Pos",(DLookUp("[AN/BP]","[qCompatibility]")), IIf([Text111]="A Neg" And
[Text168]="B Neg",(DLookUp("[AN/BN]","[qCompatibility]")),
IIf([Text111]="A Neg" And [Text168]="O
Pos",(DLookUp("[AN/OP]","[qCompatibility]")), IIf([Text111]="A Neg" And
[Text168]="O Neg",(DLookUp("[AN/ON]","[qCompatibility]")),
IIf([Text111]="A Neg" And [Text168]="AB
Pos",(DLookUp("[AN/ABP]","[qCompatibility]")), IIf([Text111]="A Neg"
And [Text168]="AB Neg",(DLookUp("[AN/ABN]","[qCompatibility]")),

IIf([Text111]="B Pos" And [Text168]="A
Pos",(DLookUp("[BP/AP]","[qCompatibility]")), IIf([Text111]="B Pos" And
[Text168]="A Neg",(DLookUp("[BP/AN]","[qCompatibility]")),
IIf([Text111]="B Pos" And [Text168]="B
Pos",(DLookUp("[BP/BP]","[qCompatibility]")), IIf([Text111]="B Pos" And
[Text168]="B Neg",(DLookUp("[BP/BN]","[qCompatibility]")),
IIf([Text111]="B Pos" And [Text168]="O
Pos",(DLookUp("[BP/OP]","[qCompatibility]")), IIf([Text111]="B Pos" And
[Text168]="O Neg",(DLookUp("[BP/ON]","[qCompatibility]")),
IIf([Text111]="B Pos" And [Text168]="AB
Pos",(DLookUp("[BP/ABP]","[qCompatibility]")), IIf([Text111]="B Pos"
And [Text168]="AB Neg",(DLookUp("[BP/ABN]","[qCompatibility]")),

IIf([Text111]="B Neg" And [Text168]="A
Pos",(DLookUp("[BN/AP]","[qCompatibility]")), IIf([Text111]="B Neg" And
[Text168]="A Neg",(DLookUp("[BN/AN]","[qCompatibility]")),
IIf([Text111]="B Neg" And [Text168]="B
Pos",(DLookUp("[BN/BP]","[qCompatibility]")), IIf([Text111]="B Neg" And
[Text168]="B Neg",(DLookUp("[BN/BN]","[qCompatibility]")),
IIf([Text111]="B Neg" And [Text168]="O
Pos",(DLookUp("[BN/OP]","[qCompatibility]")), IIf([Text111]="B Neg" And
[Text168]="O Neg",(DLookUp("[BN/ON]","[qCompatibility]")),
IIf([Text111]="B Neg" And [Text168]="AB
Pos",(DLookUp("[BN/ABP]","[qCompatibility]")), IIf([Text111]="B Neg"
And [Text168]="AB Neg",(DLookUp("[BN/ABN]","[qCompatibility]")),

IIf([Text111]="AB Pos" And [Text168]="A
Pos",(DLookUp("[ABP/AP]","[qCompatibility]")), IIf([Text111]="AB Pos"
And [Text168]="A Neg",(DLookUp("[ABP/AN]","[qCompatibility]")),
IIf([Text111]="AB Pos" And [Text168]="B
Pos",(DLookUp("[ABP/BP]","[qCompatibility]")), IIf([Text111]="AB Pos"
And [Text168]="B Neg",(DLookUp("[ABP/BN]","[qCompatibility]")),
IIf([Text111]="AB Pos" And [Text168]="O
Pos",(DLookUp("[ABP/OP]","[qCompatibility]")), IIf([Text111]="AB Pos"
And [Text168]="O Neg",(DLookUp("[ABP/ON]","[qCompatibility]")),
IIf([Text111]="AB Pos" And [Text168]="AB
Pos",(DLookUp("[ABP/ABP]","[qCompatibility]")), IIf([Text111]="AB Pos"
And [Text168]="AB Neg",(DLookUp("[ABP/ABN]","[qCompatibility]")),

IIf([Text111]="AB Neg" And [Text168]="A
Pos",(DLookUp("[ABN/AP]","[qCompatibility]")), IIf([Text111]="AB Neg"
And [Text168]="A Neg",(DLookUp("[ABN/AN]","[qCompatibility]")),
IIf([Text111]="AB Neg" And [Text168]="B
Pos",(DLookUp("[ABN/BP]","[qCompatibility]")), IIf([Text111]="AB Neg"
And [Text168]="B Neg",(DLookUp("[ABN/BN]","[qCompatibility]")),
IIf([Text111]="AB Neg" And [Text168]="O
Pos",(DLookUp("[ABN/OP]","[qCompatibility]")), IIf([Text111]="AB Neg"
And [Text168]="O Neg",(DLookUp("[ABN/ON]","[qCompatibility]")),
IIf([Text111]="AB Neg" And [Text168]="AB
Pos",(DLookUp("[ABN/ABP]","[qCompatibility]")), IIf([Text111]="AB Neg"
And [Text168]="AB Neg",(DLookUp("[ABN/ABN]","[qCompatibility]")),

IIf([Text111]="O Pos" And [Text168]="A
Pos",(DLookUp("[OP/AP]","[qCompatibility]")), IIf([Text111]="O Pos" And
[Text168]="A Neg",(DLookUp("[OP/AN]","[qCompatibility]")),
IIf([Text111]="O Pos" And [Text168]="B
Pos",(DLookUp("[OP/BP]","[qCompatibility]")), IIf([Text111]="O Pos" And
[Text168]="B Neg",(DLookUp("[OP/BN]","[qCompatibility]")),
IIf([Text111]="O Pos" And [Text168]="O
Pos",(DLookUp("[OP/OP]","[qCompatibility]")), IIf([Text111]="O Pos" And
[Text168]="O Neg",(DLookUp("[OP/ON]","[qCompatibility]")),
IIf([Text111]="O Pos" And [Text168]="AB
Pos",(DLookUp("[OP/ABP]","[qCompatibility]")), IIf([Text111]="O Pos"
And [Text168]="AB Neg",(DLookUp("[OP/ABN]","[qCompatibility]")),

IIf([Text111]="O Neg" And [Text168]="A
Pos",(DLookUp("[ON/AP]","[qCompatibility]")), IIf([Text111]="O Neg" And
[Text168]="A Neg",(DLookUp("[ON/AN]","[qCompatibility]")),
IIf([Text111]="O Neg" And [Text168]="B
Pos",(DLookUp("[ON/BP]","[qCompatibility]")), IIf([Text111]="O Neg" And
[Text168]="B Neg",(DLookUp("[ON/BN]","[qCompatibility]")),
IIf([Text111]="O Neg" And [Text168]="O
Pos",(DLookUp("[ON/OP]","[qCompatibility]")), IIf([Text111]="O Neg" And
[Text168]="O Neg",(DLookUp("[ON/ON]","[qCompatibility]")),
IIf([Text111]="O Neg" And [Text168]="AB
Pos",(DLookUp("[ON/ABP]","[qCompatibility]")), IIf([Text111]="O Neg"
And [Text168]="AB Neg",(DLookUp("[ON/ABN]","[qCompatibility]")),

"<<<Error>>>"))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))

[Tom van Stiphout]

On 21 Dec 2006 18:11:48 -0800, nj*********@gmail.com wrote:

Even if it worked, it would be horribly slow with a couple of dozen
DLookups.
I don't know your database design or the purpose of this query, but
there must be a MUCH better solution. Keep looking.

It's possible the query is so bad because the db design is bad. I
noticed you pick up different fields like "AP/AN" or "AP/BN" based on
conditions. What if your design had a single XxxTypeID field rather
than XxxType1, XxxType2, XxxType3 etc fields. It seems your current
design includes "repeating groups" which is a no-no in a normalized
database design.

-Tom.

>I thought the length of this might give me problems. Any suggestions
on how to shorten it?

Expression:

<clip>

[Kelii]

Just a thought, but you may have better luck with a select case
statement. For example:

Select Case Text168, Text 111
Case APos, ABNeg
Insert lookup here....
Case etc....
End Select

I believe Access will be able to cycle through your cases much faster
than embedded If statements. Further, you should locate your Select
Case statement in VBA rather than the data source property of a
control.

Hope that helps.

Kelii

[njgreen2001]

I'm sure exactly how to describe it. It is a blood component issueing
database for Blood Banks. There is a user settings panel where the
user specifies which blood components are used in the lab as well as
which component blood types are compatible with patient blood types.
There are 8 blood types which gives 64 combinations (Grid of 8x8
slectable options for each blood component). The user will select
"Compatible" or "Not Compatible" for each combination. (Different labs
may use different rules for some components, so I had to make it easy
for the user to change.) I temporarily solved it by breaking the
expression into 8 segments (8 text boxes), and making the text boxes
trnasparent and stacked on top of each other. Crude, but it works.
There does not seem to be any noticeable slowdown. I'm sure there may
be a better way, and I will keep racking my brain and anyone elses who
replys to this. :-)
Tom van Stiphout wrote:

On 21 Dec 2006 18:11:48 -0800, nj*********@gmail.com wrote:

Even if it worked, it would be horribly slow with a couple of dozen
DLookups.
I don't know your database design or the purpose of this query, but
there must be a MUCH better solution. Keep looking.

It's possible the query is so bad because the db design is bad. I
noticed you pick up different fields like "AP/AN" or "AP/BN" based on
conditions. What if your design had a single XxxTypeID field rather
than XxxType1, XxxType2, XxxType3 etc fields. It seems your current
design includes "repeating groups" which is a no-no in a normalized
database design.

-Tom.

I thought the length of this might give me problems. Any suggestions
on how to shorten it?

Expression:

<clip>

[njgreen2001]

Thus far, I have only had to enter anything in VBA once, and it took
forever for me to get right. Where exactly do I put this? Or does it
matter? Is there any advantage other than speed? If it's in VBA, then
what do I set the control source as? I've never had to use Select Case
either. Maybe I should go read up a bit...
Kelii wrote:

Just a thought, but you may have better luck with a select case
statement. For example:

Select Case Text168, Text 111
Case APos, ABNeg
Insert lookup here....
Case etc....
End Select

I believe Access will be able to cycle through your cases much faster
than embedded If statements. Further, you should locate your Select
Case statement in VBA rather than the data source property of a
control.

Hope that helps.

Kelii

[Tim Marshall]

nj*********@gmail.com wrote:

I'm sure exactly how to describe it. It is a blood component issueing
database for Blood Banks. There is a user settings panel where the
user specifies which blood components are used in the lab as well as
which component blood types are compatible with patient blood types.

As Tom says, your structure is either &*^%ed or you're going at this
completely the wrong way - dlookups are very, very sloppy to use in an
SQL statement.

If someone came into my office with what you posted, I'd thrown him out
immediately and speak to Human Resources about getting me another
developer. For both the awful use of dlookups and the total lack of a
naming convention for your form controls. Plus it looks as if you're
using text boxes where combo or list boxes are far more appropriate.
Use of slashes for field names is not a good idea either.

Use VBA to translate choices a user makes into a more legible SQL.
SOmething similar to the following air code:

function fWriteSql() as string
'The ridiculous "text111" and "text168" have been renamed
dim strS as string
strS = ""
if me.txtBloodType1 = "A Pos" then
select case me.txtBlootType2
case "A Pos"
Strs = "Select [AP/AP]"
case "A Neg"
strs = "Select [AP/AN]"
case "B Pos"
strs = "Select [AP/BP]"
case "B Neg"
strs = "Select [AP/BN]"
'etc, etc
end select
end if
strs = strs & " from qCompatibility"

etc.

Personally, from your other posts, in my opinion, you're making a mess
of this. Get someone who knows what they are doing to do this.
Especially if it's as something important sounding as blood typing.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Tim Marshall]

Tim Marshall wrote:

Personally, from your other posts, in my opinion, you're making a mess
of this. Get someone who knows what they are doing to do this.
Especially if it's as something important sounding as blood typing.

That sounds brutal of me, especially at this time of year. I'm sorry.
But your data structure seems to be totally out to lunch - as Tom
suggests, you should have one field called Blood_Type or something and
not an individual separate field for each type. I suspect you've done
stuff using Excel or some other spreadsheet program. However, databases
are *NOT* spreadsheets.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[David F Cox]

It seems to me that there are not 64 valid combinations, and, unless there
is another factor that you have not told us about, these do not change from
patient to patient.

If this is right then I would tackle this with a little table with fields
for component and blood types which just contained valid combinations. The
primary key of this table would define the valid combination. This
structurewould allow you to select a particular valid combination from a
combo box, and enable you to easily produce queries for valid components for
a blood type, or blood types that matched a component.

"Compatible" or "Not Compatible" for each combination...

This suggest to me a boolean field, which gives Yes/No or True/False as its
options. (just different ways of looking at the same thing.)

My apologies if I have not understood the application.
..
<nj*********@gmail.comwrote in message
news:11**********************@80g2000cwy.googlegro ups.com...

I'm sure exactly how to describe it. It is a blood component issueing
database for Blood Banks. There is a user settings panel where the
user specifies which blood components are used in the lab as well as
which component blood types are compatible with patient blood types.
There are 8 blood types which gives 64 combinations (Grid of 8x8
slectable options for each blood component). The user will select
"Compatible" or "Not Compatible" for each combination. (Different labs
may use different rules for some components, so I had to make it easy
for the user to change.) I temporarily solved it by breaking the
expression into 8 segments (8 text boxes), and making the text boxes
trnasparent and stacked on top of each other. Crude, but it works.
There does not seem to be any noticeable slowdown. I'm sure there may
be a better way, and I will keep racking my brain and anyone elses who
replys to this. :-)
Tom van Stiphout wrote:

>On 21 Dec 2006 18:11:48 -0800, nj*********@gmail.com wrote:

Even if it worked, it would be horribly slow with a couple of dozen
DLookups.
I don't know your database design or the purpose of this query, but
there must be a MUCH better solution. Keep looking.

It's possible the query is so bad because the db design is bad. I
noticed you pick up different fields like "AP/AN" or "AP/BN" based on
conditions. What if your design had a single XxxTypeID field rather
than XxxType1, XxxType2, XxxType3 etc fields. It seems your current
design includes "repeating groups" which is a no-no in a normalized
database design.

-Tom.

>I thought the length of this might give me problems. Any suggestions
on how to shorten it?

Expression:

<clip>

[Tom van Stiphout]

On Fri, 22 Dec 2006 01:35:41 -0330, Tim Marshall
<TI****@PurplePandaChasers.Moertheriumwrote:

I do agree with everything you're saying. I've seen a lot of code here
in this NG from rookies working on important sounding applications,
financial apps, etc. I hope never to need the services of such
company.
One attribute of a good developer is to know when he/she is in over
his/her head. "Sorry boss, I need help with this." "I don't feel
comfortable proceeding without someone validating my design." In our
company you get bonus points for statements like this, whereas
tinkering until it (almost) works is very much frowned upon.

-Tom.

>Tim Marshall wrote:

>Personally, from your other posts, in my opinion, you're making a mess
of this. Get someone who knows what they are doing to do this.
Especially if it's as something important sounding as blood typing.

That sounds brutal of me, especially at this time of year. I'm sorry.
But your data structure seems to be totally out to lunch - as Tom
suggests, you should have one field called Blood_Type or something and
not an individual separate field for each type. I suspect you've done
stuff using Excel or some other spreadsheet program. However, databases
are *NOT* spreadsheets.

[njgreen2001]

I'm sure there are better ways to make the database, but since it's my
first time trying to develop an Access database, and it's more for the
experience than anything, I didn't expect it to be perfect. I'm sure
none of your first Access projects were perfect either. :-) (I am NOT
doing this for $) Thanks to those offering their support. I am not so
sure I have effectively captured the description of what I'm doing,
however. There are indeed 64 unique combinations of patient blood type
to component blood type. A Pos partient to A Pos component, A Pos
patient to A Neg component, etc. What happens is this. For each
compatibility can change between components. Example: An O Pos patient
can take A Pos Plasma, but not A Pos Blood Cells. There are many
other components that various labs may define as being "compatible" or
"incompatible." For instance one lab may have a policy to transfuse
any type of Cryoprecipitate to any type of patient, other labs may only
allow type-specific. So in a control panel I have these set to be user
editable. For each component the user can select "compatible" or
"incompatible" for each combination of blood types (64). Then in the
component issue form when matching a component to a patient, the
database looks at the kind of component and the component and patient
blood types, looks at whether it is compatible or not, then simply
displayes in a trnasparent text box whether it is compatible or
incompatible. Hopefully that makes it a little more clear.
David F Cox wrote:

It seems to me that there are not 64 valid combinations, and, unless there
is another factor that you have not told us about, these do not change from
patient to patient.

If this is right then I would tackle this with a little table with fields
for component and blood types which just contained valid combinations. The
primary key of this table would define the valid combination. This
structurewould allow you to select a particular valid combination from a
combo box, and enable you to easily produce queries for valid components for
a blood type, or blood types that matched a component.

"Compatible" or "Not Compatible" for each combination...

This suggest to me a boolean field, which gives Yes/No or True/False as its
options. (just different ways of looking at the same thing.)

My apologies if I have not understood the application.
.
<nj*********@gmail.comwrote in message
news:11**********************@80g2000cwy.googlegro ups.com...

I'm sure exactly how to describe it. It is a blood component issueing
database for Blood Banks. There is a user settings panel where the
user specifies which blood components are used in the lab as well as
which component blood types are compatible with patient blood types.
There are 8 blood types which gives 64 combinations (Grid of 8x8
slectable options for each blood component). The user will select
"Compatible" or "Not Compatible" for each combination. (Different labs
may use different rules for some components, so I had to make it easy
for the user to change.) I temporarily solved it by breaking the
expression into 8 segments (8 text boxes), and making the text boxes
trnasparent and stacked on top of each other. Crude, but it works.
There does not seem to be any noticeable slowdown. I'm sure there may
be a better way, and I will keep racking my brain and anyone elses who
replys to this. :-)
Tom van Stiphout wrote:

On 21 Dec 2006 18:11:48 -0800, nj*********@gmail.com wrote:

Even if it worked, it would be horribly slow with a couple of dozen
DLookups.
I don't know your database design or the purpose of this query, but
there must be a MUCH better solution. Keep looking.

It's possible the query is so bad because the db design is bad. I
noticed you pick up different fields like "AP/AN" or "AP/BN" based on
conditions. What if your design had a single XxxTypeID field rather
than XxxType1, XxxType2, XxxType3 etc fields. It seems your current
design includes "repeating groups" which is a no-no in a normalized
database design.

-Tom.

I thought the length of this might give me problems. Any suggestions
on how to shorten it?

Expression:

<clip>

[David W. Fenton]

nj*********@gmail.com wrote in
news:11**********************@48g2000cwx.googlegro ups.com:

I thought the length of this might give me problems. Any
suggestions on how to shorten it?

[horrid expression deleted]

On principle, I consider any query that uses a DLookup to be
wrongly-designed. Why can't you add the source tables to the query
itself and get the information from them directly? This will be many
times more efficient.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

Tim Marshall <TI****@PurplePandaChasers.Moertheriumwrote in
news:em**********@coranto.ucs.mun.ca:

Tim Marshall wrote:

>Personally, from your other posts, in my opinion, you're making a
mess of this. Get someone who knows what they are doing to do
this. Especially if it's as something important sounding as blood
typing.

That sounds brutal of me, especially at this time of year. I'm
sorry.

You might not be surprised to hear that I consider it a perfectly
valid point, properly expressed.

And what does the time of year have to do with it? If it's wrong,
it's wrong -- we don't change the rules for the holidays. And if
you're worrying about it being blunt, why should one worry about
giving offense only around the holidays? Why not worry about that
all year 'round, or, like me, never worry about it at all?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[njgreen2001]

The query does not use a DLookup. That mess is all in the control
source of a text box. (Now broken up into 8 text boxes--see above.)
David W. Fenton wrote:

nj*********@gmail.com wrote in
news:11**********************@48g2000cwx.googlegro ups.com:

I thought the length of this might give me problems. Any
suggestions on how to shorten it?

[horrid expression deleted]

On principle, I consider any query that uses a DLookup to be
wrongly-designed. Why can't you add the source tables to the query
itself and get the information from them directly? This will be many
times more efficient.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Kelii]

njgreen,

Indeed learning to write VBA code is difficult, but the learning curve
is steep, in the sense that you can start doing quite a bit with just a
little bit of studying up on the language. Since you are primarily
doing this for the experience, I, for one, would suggest that VBA is an
indespensible (sp?) component of any well built and user friendly
database.

In regards to the other posts on your topic, your tables are very
likely to be "hamajanged" as we used to say. That said, data
normalization (which is what your database design is missing) is
relatively straightforward (some may disagree), and is almost always
included in books regarding Access.

All that said, you can find several eBooks on Access databases, and VBA
programming on any Bistream webiste; not that I endorse that type of
activity.

To your question:
You would put a reference to the Select Case statement behind the
"After Update" event of your Text111 and Text168 objects (which should
probably be combo boxes). The code would read similar to an earlier
post in this thread:

Private Sub Text111_After_Update (Cancel As Integer)

DescribeFunction

End Sub

---------------------------------

Private Sub Text168_After_Update (Cancel As Integer)

DescribeFunction

End Sub

---------------------------------

Private Sub DescribeFunction ()

Select Case Text111
Case OPos
Select Case Text 168
Case ANeg
txtResult = Insert rest of function here
Case ...
End Select
Case ANeg
Insert rest of function
End Select

End Sub

Without having an intimate knowledge of your data design, form design,
and application needs, I (personally) have a hard time giving much more
in the way of detail regarding how to execute. However, I can say that
with a bit of reading on your part, you will be able to your task much
more elegantly, and quickly.

Best,

Kelii

[Tim Marshall]

Tom van Stiphout wrote:

In our
company you get bonus points for statements like this, whereas
tinkering until it (almost) works is very much frowned upon.

Wow, that's great to hear, but I bet you guys are in a minority! This
is the polar opposite of the programming/development department in my
organization (though, hopefully they've changed after they deal with me
as a very dissatisfied manager a couple of years ago).
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[Tim Marshall]

David W. Fenton wrote:

And what does the time of year have to do with it? If it's wrong,
it's wrong -- we don't change the rules for the holidays. And if
you're worrying about it being blunt, why should one worry about
giving offense only around the holidays? Why not worry about that
all year 'round, or, like me, never worry about it at all?

It's actually nice to hear I'm not the only one whose stomach turns at
the way people (well actually, the mass media of material advertizing)
try to artificially change behaviour because of a time of year. And I'm
a practicing Christian.

It's a hopeless task though, trying to make people understand that as
we've all been very programmed from almost birth about the "magic of the
Christmas season". The only magic is how retaillers are able to turn a
year around in a short period of time...
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[David W. Fenton]

nj*********@gmail.com wrote in
news:11**********************@a3g2000cwd.googlegro ups.com:

The query does not use a DLookup. That mess is all in the control
source of a text box. (Now broken up into 8 text boxes--see
above.)

That really just displaces the question as to why it's not in the
recordsource of the form.

Or why you haven't written an efficient function that does a single
lookup to get the right value.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[David W. Fenton]

Tim Marshall <TI****@PurplePandaChasers.Moertheriumwrote in
news:em**********@coranto.ucs.mun.ca:

David W. Fenton wrote:

>And what does the time of year have to do with it? If it's wrong,
it's wrong -- we don't change the rules for the holidays. And if
you're worrying about it being blunt, why should one worry about
giving offense only around the holidays? Why not worry about that
all year 'round, or, like me, never worry about it at all?

It's actually nice to hear I'm not the only one whose stomach
turns at the way people (well actually, the mass media of material
advertizing) try to artificially change behaviour because of a
time of year. And I'm a practicing Christian.

It's a hopeless task though, trying to make people understand that
as we've all been very programmed from almost birth about the
"magic of the Christmas season". The only magic is how retaillers
are able to turn a year around in a short period of time...

You realize, of course, that you've misread my point, which is that
EVERYONE SHOULD BE RUDE YEAR-ROUND!!!

;)

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Tim Marshall]

David W. Fenton wrote:

You realize, of course, that you've misread my point, which is that
EVERYONE SHOULD BE RUDE YEAR-ROUND!!!

I didn't miss it, I just chose to be optimistic.... 8)
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me