Moving an expression generated value into table through form

G

Guest

As I update a record through a subform based on a Query of the Child Table…I
want the new current date to be placed in an assigned field in the Parent
table. I added a new field in the Parent table (a date field)…I pulled this
field to my main form in a section above the subform. In the control source
for this field I have inserted the following:

=DMax("[ReadOn]","[Child Query]","[ParentTable_ID] = " & [ID])

This displays the new current date in the text box for the field on the
form. The date displays correctly when updated…..but the value does not move
into the Parent Table. Anyone have an idea? Thank you.
 
G

Guest

Hi, Jeff.

A control can either be bound to an underlying field, in which case its
Control Source is the name of that field, or to a calculation; it cannot be
both simultaneously. Since this value can be calculated on the fly at any
time on your form or in a query faster than it could be looked up from disk,
however, it doesn't need to be stored.

For those very rare occasions where it does make sense to store a calculated
value, you can add another textbox, make it invisible, bind it to the field,
and set its value as appropriate:

Me![MyInvisibleBoundTextbox] = Me![MyCalculatedTextBox]

Hope that helps.
Sprinks
 
G

Guest

I have reports and notices sent to 40 different departments based on the most
recent date in a field. Currently everything points to this particular field
in the Parent Table/Main Form. To keep track of history I now have a child
table and query onwhich a subform is based which I added to the body of my
Main Form. Now as records are updated through the subform..the history is
kept but ...

Now I need a way of isolating that new..most recent date so that I have
something for my reports and notices to point to. Once I find that I am
hoping to go through each one replacing the old [currentdatefield]. Does
this make sense?

Sprinks said:
Hi, Jeff.

A control can either be bound to an underlying field, in which case its
Control Source is the name of that field, or to a calculation; it cannot be
both simultaneously. Since this value can be calculated on the fly at any
time on your form or in a query faster than it could be looked up from disk,
however, it doesn't need to be stored.

For those very rare occasions where it does make sense to store a calculated
value, you can add another textbox, make it invisible, bind it to the field,
and set its value as appropriate:

Me![MyInvisibleBoundTextbox] = Me![MyCalculatedTextBox]

Hope that helps.
Sprinks

Jeff C said:
As I update a record through a subform based on a Query of the Child Table…I
want the new current date to be placed in an assigned field in the Parent
table. I added a new field in the Parent table (a date field)…I pulled this
field to my main form in a section above the subform. In the control source
for this field I have inserted the following:

=DMax("[ReadOn]","[Child Query]","[ParentTable_ID] = " & [ID])

This displays the new current date in the text box for the field on the
form. The date displays correctly when updated…..but the value does not move
into the Parent Table. Anyone have an idea? Thank you.
 
G

Guest

Hi, Jeff.

I understand your need for the date, but unless I'm missing something, you
can base your reports on a query, and include a calculated field in the query
that calculates the date the same way you do on your form.

My only concern about storing the calculation is should users have access to
the tables directly outside the context of your entry forms, the date in your
main table would be out of date.

Jeff C said:
I have reports and notices sent to 40 different departments based on the most
recent date in a field. Currently everything points to this particular field
in the Parent Table/Main Form. To keep track of history I now have a child
table and query onwhich a subform is based which I added to the body of my
Main Form. Now as records are updated through the subform..the history is
kept but ...

Now I need a way of isolating that new..most recent date so that I have
something for my reports and notices to point to. Once I find that I am
hoping to go through each one replacing the old [currentdatefield]. Does
this make sense?

Sprinks said:
Hi, Jeff.

A control can either be bound to an underlying field, in which case its
Control Source is the name of that field, or to a calculation; it cannot be
both simultaneously. Since this value can be calculated on the fly at any
time on your form or in a query faster than it could be looked up from disk,
however, it doesn't need to be stored.

For those very rare occasions where it does make sense to store a calculated
value, you can add another textbox, make it invisible, bind it to the field,
and set its value as appropriate:

Me![MyInvisibleBoundTextbox] = Me![MyCalculatedTextBox]

Hope that helps.
Sprinks

Jeff C said:
As I update a record through a subform based on a Query of the Child Table…I
want the new current date to be placed in an assigned field in the Parent
table. I added a new field in the Parent table (a date field)…I pulled this
field to my main form in a section above the subform. In the control source
for this field I have inserted the following:

=DMax("[ReadOn]","[Child Query]","[ParentTable_ID] = " & [ID])

This displays the new current date in the text box for the field on the
form. The date displays correctly when updated…..but the value does not move
into the Parent Table. Anyone have an idea? Thank you.
 
G

Guest

I finally made this dog hunt....have a query ... it works...tested it on
the reports, will just need to copy and paste the filter expression for each
report before I switch the Report Source unless someone suggests a better
way. Thank you all for your input.

Sprinks said:
Hi, Jeff.

I understand your need for the date, but unless I'm missing something, you
can base your reports on a query, and include a calculated field in the query
that calculates the date the same way you do on your form.

My only concern about storing the calculation is should users have access to
the tables directly outside the context of your entry forms, the date in your
main table would be out of date.

Jeff C said:
I have reports and notices sent to 40 different departments based on the most
recent date in a field. Currently everything points to this particular field
in the Parent Table/Main Form. To keep track of history I now have a child
table and query onwhich a subform is based which I added to the body of my
Main Form. Now as records are updated through the subform..the history is
kept but ...

Now I need a way of isolating that new..most recent date so that I have
something for my reports and notices to point to. Once I find that I am
hoping to go through each one replacing the old [currentdatefield]. Does
this make sense?

Sprinks said:
Hi, Jeff.

A control can either be bound to an underlying field, in which case its
Control Source is the name of that field, or to a calculation; it cannot be
both simultaneously. Since this value can be calculated on the fly at any
time on your form or in a query faster than it could be looked up from disk,
however, it doesn't need to be stored.

For those very rare occasions where it does make sense to store a calculated
value, you can add another textbox, make it invisible, bind it to the field,
and set its value as appropriate:

Me![MyInvisibleBoundTextbox] = Me![MyCalculatedTextBox]

Hope that helps.
Sprinks

:

As I update a record through a subform based on a Query of the Child Table…I
want the new current date to be placed in an assigned field in the Parent
table. I added a new field in the Parent table (a date field)…I pulled this
field to my main form in a section above the subform. In the control source
for this field I have inserted the following:

=DMax("[ReadOn]","[Child Query]","[ParentTable_ID] = " & [ID])

This displays the new current date in the text box for the field on the
form. The date displays correctly when updated…..but the value does not move
into the Parent Table. Anyone have an idea? Thank you.
 
J

John Vinson

I finally made this dog hunt....have a query ... it works...tested it on
the reports, will just need to copy and paste the filter expression for each
report before I switch the Report Source unless someone suggests a better
way. Thank you all for your input.

Nope. No copy and paste, and no modification of the query should be
needed!

Where are you getting the filter expression? The Query should be able
to pull it directly.

John W. Vinson[MVP]
 
G

Guest

My reports all point to the Parent table. I now have a child table and query
simply named Child_Query.

I had to reassign the source for my reports (I just played with it today) so
when I switched from the parent table to the Query.....the control source for
the report went away.

I am only 3 months old in Access now....I put expressions in the control
source for all my reports to act like filters...and they work....so, that's
next weeks project. I'll keep listening to you. Thanks.
 
J

John Vinson

I had to reassign the source for my reports (I just played with it today) so
when I switched from the parent table to the Query.....the control source for
the report went away.

I think you may need another Query, one linking your parent table to
the child table. But I don't know how your tables or your report are
structured.
I am only 3 months old in Access now....I put expressions in the control
source for all my reports to act like filters...and they work....so, that's
next weeks project. I'll keep listening to you. Thanks.

If you'll keep *talking* that will help too - for one thing, Reports
have Recordsource properties; they do not have a Control Source, so I
have no idea what you mean by "put expressions in the control source
for all my reports to act like filters". The Report should be based on
a query where the filtering gets done.

John W. Vinson[MVP]
 
G

Guest

Well John, of course you are correct...the Record Source for my reports are
the Parent table. My filters are written in the Filter property and Filters
are turned on.

A typical Filter is as follows:
([Dept]=605 and [active]=yes) and ([Bi-Annual Test]=yes and month([current
test date])=month(DateAdd("m",-6,Date()))) or ([Dept]=605 and [active]=yes)
and ([Annual Test]=yes and month([current test
date])=month(DateAdd("m",-12,Date())))

I now have a Child Table that holds [current test date] and the history with
a Query based on the Child Table and including neccessary fields from the
Parent Table. The Query works as the record source for the reports and as
the basis for a subform to record and transfer history information for each
test.

My thought was just to keep the filters the way they are in the reports but
maybe there is a better way. Thank You.
 
J

John Vinson

Well John, of course you are correct...the Record Source for my reports are
the Parent table. My filters are written in the Filter property and Filters
are turned on.

A typical Filter is as follows:
([Dept]=605 and [active]=yes) and ([Bi-Annual Test]=yes and month([current
test date])=month(DateAdd("m",-6,Date()))) or ([Dept]=605 and [active]=yes)
and ([Annual Test]=yes and month([current test
date])=month(DateAdd("m",-12,Date())))

I now have a Child Table that holds [current test date] and the history with
a Query based on the Child Table and including neccessary fields from the
Parent Table. The Query works as the record source for the reports and as
the basis for a subform to record and transfer history information for each
test.

My thought was just to keep the filters the way they are in the reports but
maybe there is a better way. Thank You.

There is indeed a better way. Using the Filter property of the report
forces Access to retrieve all the records in your table - and then
throw most of them away.

Try this instead: base your Form on the Parent table, and your subform
on the Child table. The child table should hold *JUST* the history; it
should have a date field recording the date of the test (I presume),
but I don't think it should be necessary to store the "most current
test data" anywhere. It can always be found using a query or the
DMax() function we've discussed.

For the Report, create a Query joining the parent and child tables,
selecting whichever fields you want to display. On the Criteria of
this query put the same criteria as your filter; if by [current test
date] you mean the most recent date in the History table, replace
[current test date] with

DMax("[test date]", "[history table]", "<whatever criteria>")

to select the most recent relevant test date. I don't know how your
history table is set up or what subset of records you want to search -
tests for a department maybe? - but the <whatever criteria> would
resemble your filter criteria, I'd guess.

John W. Vinson[MVP]
 
G

Guest

OK...I think I am understanding the concepts better now. My subform was
based on my child table...but I made a query basing my subform on it with
your help yesterday so it would display the test history in chronological
order..begining with the most recent..this serves another purpose of the
form. Part of this purpose is setting the "most recent date" apart with
emphasis and it does now ...really solving that aspect.

Now if I understand correctly....the reports should reflect a query....?

So, basically using my filter criteria for each report (about 120) I would
build a query for each report....and then I will rewrite a report for each
query? I also have about 80 macros which automate e-mails to 40 depts
sending them .snp reports 3 times a month.

John Vinson said:
Well John, of course you are correct...the Record Source for my reports are
the Parent table. My filters are written in the Filter property and Filters
are turned on.

A typical Filter is as follows:
([Dept]=605 and [active]=yes) and ([Bi-Annual Test]=yes and month([current
test date])=month(DateAdd("m",-6,Date()))) or ([Dept]=605 and [active]=yes)
and ([Annual Test]=yes and month([current test
date])=month(DateAdd("m",-12,Date())))

I now have a Child Table that holds [current test date] and the history with
a Query based on the Child Table and including neccessary fields from the
Parent Table. The Query works as the record source for the reports and as
the basis for a subform to record and transfer history information for each
test.

My thought was just to keep the filters the way they are in the reports but
maybe there is a better way. Thank You.

There is indeed a better way. Using the Filter property of the report
forces Access to retrieve all the records in your table - and then
throw most of them away.

Try this instead: base your Form on the Parent table, and your subform
on the Child table. The child table should hold *JUST* the history; it
should have a date field recording the date of the test (I presume),
but I don't think it should be necessary to store the "most current
test data" anywhere. It can always be found using a query or the
DMax() function we've discussed.

For the Report, create a Query joining the parent and child tables,
selecting whichever fields you want to display. On the Criteria of
this query put the same criteria as your filter; if by [current test
date] you mean the most recent date in the History table, replace
[current test date] with

DMax("[test date]", "[history table]", "<whatever criteria>")

to select the most recent relevant test date. I don't know how your
history table is set up or what subset of records you want to search -
tests for a department maybe? - but the <whatever criteria> would
resemble your filter criteria, I'd guess.

John W. Vinson[MVP]
 
J

John Vinson

OK...I think I am understanding the concepts better now. My subform was
based on my child table...but I made a query basing my subform on it with
your help yesterday so it would display the test history in chronological
order..begining with the most recent..this serves another purpose of the
form. Part of this purpose is setting the "most recent date" apart with
emphasis and it does now ...really solving that aspect.
Good!

Now if I understand correctly....the reports should reflect a query....?

I don't use the term "reflect".

You want your Report to print out a selected subset of the data in the
tables, rather than the entire table. Right?

A Query is just that: a way of getting a selective subset of the
Table. Simply base your Report on the Query which retrieves the
desired subset of the table. It's not "reflecting" it; it's simply
putting the information in the query onto paper.
So, basically using my filter criteria for each report (about 120) I would
build a query for each report....and then I will rewrite a report for each
query? I also have about 80 macros which automate e-mails to 40 depts
sending them .snp reports 3 times a month.

No. You would have ONE SINGLE REPORT based on ONE SINGLE QUERY.

I'm strongly suspecting that you are making the very common beginner's
assumption that every time you change the value of a parameter for a
query you must create a new query, say a query with "310" in the
DepartmentID field for the Department 310 report, and with "312" for
the Department 312 report; and that you need a different report (of
identical layout and appearance) for each query.

You do NOT need to do this. Instead, use what's called a "Parameter
Query". There are several ways to do this; one would be to use a
criterion of

[Enter Department No:]

instead of

310

on the criteria line.

Better, because it's less work for the user, is to create a little
unbound Form named frmCriteria with a control (textbox, checkbox,
combo box, whatever is appropriate) for each criterion and use

=[Forms]![frmcCriteira]![cboDept]

to generate the report for that department.

Better yet, if these run in batches, would be to write VBA code to
loop through your 40 departments generating the report for each one in
a loop... but let's leave that for another post.

John W. Vinson[MVP]
 
G

Guest

I will have to think on this one tonight.......I appreciate the thought
provocing suggestions...and you are right....I AM a beginner (but so far
everything has worked...long way around the bush). Thanks John

John Vinson said:
OK...I think I am understanding the concepts better now. My subform was
based on my child table...but I made a query basing my subform on it with
your help yesterday so it would display the test history in chronological
order..begining with the most recent..this serves another purpose of the
form. Part of this purpose is setting the "most recent date" apart with
emphasis and it does now ...really solving that aspect.
Good!

Now if I understand correctly....the reports should reflect a query....?

I don't use the term "reflect".

You want your Report to print out a selected subset of the data in the
tables, rather than the entire table. Right?

A Query is just that: a way of getting a selective subset of the
Table. Simply base your Report on the Query which retrieves the
desired subset of the table. It's not "reflecting" it; it's simply
putting the information in the query onto paper.
So, basically using my filter criteria for each report (about 120) I would
build a query for each report....and then I will rewrite a report for each
query? I also have about 80 macros which automate e-mails to 40 depts
sending them .snp reports 3 times a month.

No. You would have ONE SINGLE REPORT based on ONE SINGLE QUERY.

I'm strongly suspecting that you are making the very common beginner's
assumption that every time you change the value of a parameter for a
query you must create a new query, say a query with "310" in the
DepartmentID field for the Department 310 report, and with "312" for
the Department 312 report; and that you need a different report (of
identical layout and appearance) for each query.

You do NOT need to do this. Instead, use what's called a "Parameter
Query". There are several ways to do this; one would be to use a
criterion of

[Enter Department No:]

instead of

310

on the criteria line.

Better, because it's less work for the user, is to create a little
unbound Form named frmCriteria with a control (textbox, checkbox,
combo box, whatever is appropriate) for each criterion and use

=[Forms]![frmcCriteira]![cboDept]

to generate the report for that department.

Better yet, if these run in batches, would be to write VBA code to
loop through your 40 departments generating the report for each one in
a loop... but let's leave that for another post.

John W. Vinson[MVP]
 
G

Guest

I have created a report for each department director for each of three
instances. These are set up each with a switchboard button and when each is
due or needed someone goes to the correct switchboard and clicks a
button....as simple a system as I could think of because they will not always
have me or someone knowledgable able around to generate them.

If I understand the parameter query..I have one report that requires input
for each particular circumstance which wouldn't be practical in this
application...or for director ZZ I open the query and enter 5 department #s
for her responsibility and then run the report?

John Vinson said:
OK...I think I am understanding the concepts better now. My subform was
based on my child table...but I made a query basing my subform on it with
your help yesterday so it would display the test history in chronological
order..begining with the most recent..this serves another purpose of the
form. Part of this purpose is setting the "most recent date" apart with
emphasis and it does now ...really solving that aspect.
Good!

Now if I understand correctly....the reports should reflect a query....?

I don't use the term "reflect".

You want your Report to print out a selected subset of the data in the
tables, rather than the entire table. Right?

A Query is just that: a way of getting a selective subset of the
Table. Simply base your Report on the Query which retrieves the
desired subset of the table. It's not "reflecting" it; it's simply
putting the information in the query onto paper.
So, basically using my filter criteria for each report (about 120) I would
build a query for each report....and then I will rewrite a report for each
query? I also have about 80 macros which automate e-mails to 40 depts
sending them .snp reports 3 times a month.

No. You would have ONE SINGLE REPORT based on ONE SINGLE QUERY.

I'm strongly suspecting that you are making the very common beginner's
assumption that every time you change the value of a parameter for a
query you must create a new query, say a query with "310" in the
DepartmentID field for the Department 310 report, and with "312" for
the Department 312 report; and that you need a different report (of
identical layout and appearance) for each query.

You do NOT need to do this. Instead, use what's called a "Parameter
Query". There are several ways to do this; one would be to use a
criterion of

[Enter Department No:]

instead of

310

on the criteria line.

Better, because it's less work for the user, is to create a little
unbound Form named frmCriteria with a control (textbox, checkbox,
combo box, whatever is appropriate) for each criterion and use

=[Forms]![frmcCriteira]![cboDept]

to generate the report for that department.

Better yet, if these run in batches, would be to write VBA code to
loop through your 40 departments generating the report for each one in
a loop... but let's leave that for another post.

John W. Vinson[MVP]
 
J

John Vinson

I have created a report for each department director for each of three
instances. These are set up each with a switchboard button and when each is
due or needed someone goes to the correct switchboard and clicks a
button....as simple a system as I could think of because they will not always
have me or someone knowledgable able around to generate them.

If I understand the parameter query..I have one report that requires input
for each particular circumstance which wouldn't be practical in this
application...or for director ZZ I open the query and enter 5 department #s
for her responsibility and then run the report?

Well, remember - *you* know what the criteria are for each report. I
don't. However, if you can create a query which generates the correct
list of department numbers, you can store that list of department
numbers in a table, and include that table in the Query!

I can easily imagine a table with two fields: DirectorID and
Department. For ZZ, this table would have five rows, for those five
department numbers. Your Report would include this query, with a
single criterion (which could be a COmbo Box on the switchboard,
presenting a list of the directors) to generate reports for all five
departments.

It is possible to find a middle ground between hand-coding dozens and
dozens of queries (and putting up with the possibly severe maintenance
chore of changing those queries if a director's responsibilities
change), and forcing the user to put in a lot of detail for every
report. Where that balance lies is up to you, but as a general pair of
principles I'd suggest:

A. Let the computer do as much work as it is capable of doing rather
than putting that work onto either the user or the developer
B. Put as much of variable information into Tables as possible, and no
more than necessary hardcoded into queries or code

John W. Vinson[MVP]
 
G

Guest

OK NOW that idea fliped a switch..I can play with that concept. Thank you.
I'll keep sharing my progress (and probable question) through this thread
tomorrow...Thanks John. That makes sense to me.
 
G

Guest

I have now created a table holding Director information and a Table holding
Department information..most Directors are responsible for more than one
Department.

I need to create a parameter query (3) using the criteria from the reports I
now have (3) and the parameter would be on the director.

Is it a difficult process to automate?

The other question I have is the best way to get the work I have done
matched to the database. I began with a fresh copy of the database and did
all the new table and query creation and relationship work on this. The
database has been in use and is full of 4 days worth of updates. I am
thinking that I just need to manually create the Parent and Child table and
set the relation.....but I can just copy the new form, subform and query. Am
I on the right track? Thank you.

John Vinson said:
OK...I think I am understanding the concepts better now. My subform was
based on my child table...but I made a query basing my subform on it with
your help yesterday so it would display the test history in chronological
order..begining with the most recent..this serves another purpose of the
form. Part of this purpose is setting the "most recent date" apart with
emphasis and it does now ...really solving that aspect.
Good!

Now if I understand correctly....the reports should reflect a query....?

I don't use the term "reflect".

You want your Report to print out a selected subset of the data in the
tables, rather than the entire table. Right?

A Query is just that: a way of getting a selective subset of the
Table. Simply base your Report on the Query which retrieves the
desired subset of the table. It's not "reflecting" it; it's simply
putting the information in the query onto paper.
So, basically using my filter criteria for each report (about 120) I would
build a query for each report....and then I will rewrite a report for each
query? I also have about 80 macros which automate e-mails to 40 depts
sending them .snp reports 3 times a month.

No. You would have ONE SINGLE REPORT based on ONE SINGLE QUERY.

I'm strongly suspecting that you are making the very common beginner's
assumption that every time you change the value of a parameter for a
query you must create a new query, say a query with "310" in the
DepartmentID field for the Department 310 report, and with "312" for
the Department 312 report; and that you need a different report (of
identical layout and appearance) for each query.

You do NOT need to do this. Instead, use what's called a "Parameter
Query". There are several ways to do this; one would be to use a
criterion of

[Enter Department No:]

instead of

310

on the criteria line.

Better, because it's less work for the user, is to create a little
unbound Form named frmCriteria with a control (textbox, checkbox,
combo box, whatever is appropriate) for each criterion and use

=[Forms]![frmcCriteira]![cboDept]

to generate the report for that department.

Better yet, if these run in batches, would be to write VBA code to
loop through your 40 departments generating the report for each one in
a loop... but let's leave that for another post.

John W. Vinson[MVP]
 
J

John Vinson

I have now created a table holding Director information and a Table holding
Department information..most Directors are responsible for more than one
Department.

I need to create a parameter query (3) using the criteria from the reports I
now have (3) and the parameter would be on the director.

Is it a difficult process to automate?

Shouldn't be. I'd suggest using an unbound Form - it could be your
switchboard or a form opened from your switchboard. This would have
whatever controls you need to specify the criteria needed; for
instance, if each director has a customized report, you could have a
single listbox showing the director's name. The user could select the
name and the listbox's AfterUpdate event would open the report.

If you need other criteria - a date range perhaps - the form could
have additional textboxes or other controls in which to enter those
criteria.
The other question I have is the best way to get the work I have done
matched to the database. I began with a fresh copy of the database and did
all the new table and query creation and relationship work on this. The
database has been in use and is full of 4 days worth of updates. I am
thinking that I just need to manually create the Parent and Child table and
set the relation.....but I can just copy the new form, subform and query. Am
I on the right track? Thank you.

You'll be able to use File... Get External Data... Import to import
the new director and department tables, I would presume; since I don't
know what other changes you've made I can't advise in detail.

One suggestion: if this application will be used by more than one
person simultaneously, and if you have not already done so, RUN do not
walk to the Database Splitter Wizard (Tools... Database utilities).
This will put all of the Tables into one "backend" database, shared,
and all of the forms, queries, reports, and code into a frontend
database. Each user should have their own copy of the frontend. This
will save all sorts of hassles and corruption. And - as always - KEEP
BACKUPS CURRENT!

John W. Vinson[MVP]
 
G

Guest

Having a difficult time with the query....couldn't get things to work so I
have gone back several times and added one or two fields at a time and then
run the query to isolate what I am doing wrong.

I made a query to combine the director and department info. I am using that
query and a query isolating date field [current test] and the parent table to
create a parameter query based on the director (and it works!!!...first
parameter query).

I then add the following to criteria for the [Current Test]:

Month(DateAdd("m",-6,Date()))

The query which worked fine before returns nothing when that expression is
added. What gives?
 
J

John Vinson

Having a difficult time with the query....couldn't get things to work so I
have gone back several times and added one or two fields at a time and then
run the query to isolate what I am doing wrong.

I made a query to combine the director and department info. I am using that
query and a query isolating date field [current test] and the parent table to
create a parameter query based on the director (and it works!!!...first
parameter query).

I then add the following to criteria for the [Current Test]:

Month(DateAdd("m",-6,Date()))

The query which worked fine before returns nothing when that expression is
added. What gives?

<looking under the monitor for the query>

I have no idea, Jeff. Care to post the SQL of the query? What field
are you searching with this value (which will just be an integer
number, 1 to 12)? If it's a date/time field it will certainly NOT
work.


John W. Vinson[MVP]
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top