"Calculating" message for combo

My client is getting a "calculating" indication in the status bar, and a
combo is taking 15 minutes to load. The cursor is frozen, Ctrl-Break does
not stop the "Calculating".
Eventually, the "Calculating" goes away, and the combo works well.
If the client edits any records in the table that is the source for the
combo, the
"calculating" delay occurs again.

The combo (along with 3 other exaclty similar combos) is on a continuous
subform and only contains two fields
(AttendeeID and a Last/First concatenated field), and consists of only 825
items, sorted on Last/First. The ID is indexed NoDupes and key, and
Last/First are indexed DupesOK.
There is no criteria for the combo query. There is a NoShow True/False =
True field in the query

The PC is a 2Ghz P4 with 256K of memory, and we moved the FE/BE (DATA and
PROG) files to the local drive C:... with no real difference compared to
PROG and DATA on the network server, or PROG local and DATA on the server.
I have an exact copy of the FE and BE, and it runs just fine on my P4
2.8GHz 1GB of memory.

AutoName Correct is turned off in Options.

I can not find any problem with my table design, or the combo query. 825
records is just not much of a load!

Any suggestions would be greatly appreciated.

Thanks,
Al Camp

4 * 825 = 3,300 - Each query will run independantly. Still, not a huge
number of records to search. There must be something in the query that is
slowing it down. I do see you are concatenating the name which takes a
little extra time.

Could you post the row source for the queries so we can see if there is
anything that jumps out.



"Al Camp" wrote:

My client is getting a "calculating" indication in the status bar, and a
combo is taking 15 minutes to load. The cursor is frozen, Ctrl-Break does
not stop the "Calculating".
Eventually, the "Calculating" goes away, and the combo works well.
If the client edits any records in the table that is the source for the
combo, the
"calculating" delay occurs again.

The combo (along with 3 other exaclty similar combos) is on a continuous
subform and only contains two fields
(AttendeeID and a Last/First concatenated field), and consists of only 825
items, sorted on Last/First. The ID is indexed NoDupes and key, and
Last/First are indexed DupesOK.
There is no criteria for the combo query. There is a NoShow True/False =
True field in the query

The PC is a 2Ghz P4 with 256K of memory, and we moved the FE/BE (DATA and
PROG) files to the local drive C:... with no real difference compared to
PROG and DATA on the network server, or PROG local and DATA on the server.
I have an exact copy of the FE and BE, and it runs just fine on my P4
2.8GHz 1GB of memory.

AutoName Correct is turned off in Options.

I can not find any problem with my table design, or the combo query. 825
records is just not much of a load!

Any suggestions would be greatly appreciated.

Thanks,
Al Camp

Klatuu,
Hope things are well with you...

Here's the query behind the combo...
SELECT tblAttendees.AttendeeID, [AttendeeLastName] & ", " &
[AttendeeFirstName] AS FullName FROM tblAttendees WHERE
(((tblAttendees.Active)=True)) ORDER BY [AttendeeLastName] & ", " &
[AttendeeFirstName];

Only one table involved...
It's really straight forward. For the life of me I can't figure this one
out. It works like a champ on my machine. And, I've built many apps with
more "complicated" combo sources than this. (multiple tables, pass thrus,
etc...)

Thanks for any assistance,
Al Camp

"Klatuu" wrote in message
...
4 * 825 = 3,300 - Each query will run independantly. Still, not a huge
number of records to search. There must be something in the query that is
slowing it down. I do see you are concatenating the name which takes a
little extra time.

Could you post the row source for the queries so we can see if there is
anything that jumps out.



"Al Camp" wrote:

My client is getting a "calculating" indication in the status bar, and
a
combo is taking 15 minutes to load. The cursor is frozen, Ctrl-Break
does
not stop the "Calculating".
Eventually, the "Calculating" goes away, and the combo works well.
If the client edits any records in the table that is the source for
the
combo, the
"calculating" delay occurs again.

The combo (along with 3 other exaclty similar combos) is on a
continuous
subform and only contains two fields
(AttendeeID and a Last/First concatenated field), and consists of only
825
items, sorted on Last/First. The ID is indexed NoDupes and key, and
Last/First are indexed DupesOK.
There is no criteria for the combo query. There is a NoShow True/False =
True field in the query

The PC is a 2Ghz P4 with 256K of memory, and we moved the FE/BE (DATA
and
PROG) files to the local drive C:... with no real difference compared to
PROG and DATA on the network server, or PROG local and DATA on the
server.
I have an exact copy of the FE and BE, and it runs just fine on my P4
2.8GHz 1GB of memory.

AutoName Correct is turned off in Options.

I can not find any problem with my table design, or the combo query.
825
records is just not much of a load!

Any suggestions would be greatly appreciated.

Thanks,
Al Camp

Doesn't look like it should be a problem.
Sorry to be so long getting back. I have been on a crunch time project and
had to work all weekend to be prepared for this morning.

"Al Camp" wrote:

Klatuu,
Hope things are well with you...

Here's the query behind the combo...
SELECT tblAttendees.AttendeeID, [AttendeeLastName] & ", " &
[AttendeeFirstName] AS FullName FROM tblAttendees WHERE
(((tblAttendees.Active)=True)) ORDER BY [AttendeeLastName] & ", " &
[AttendeeFirstName];

Only one table involved...
It's really straight forward. For the life of me I can't figure this one
out. It works like a champ on my machine. And, I've built many apps with
more "complicated" combo sources than this. (multiple tables, pass thrus,
etc...)

Thanks for any assistance,
Al Camp

"Klatuu" wrote in message
...
4 * 825 = 3,300 - Each query will run independantly. Still, not a huge
number of records to search. There must be something in the query that is
slowing it down. I do see you are concatenating the name which takes a
little extra time.

Could you post the row source for the queries so we can see if there is
anything that jumps out.



"Al Camp" wrote:

My client is getting a "calculating" indication in the status bar, and
a
combo is taking 15 minutes to load. The cursor is frozen, Ctrl-Break
does
not stop the "Calculating".
Eventually, the "Calculating" goes away, and the combo works well.
If the client edits any records in the table that is the source for
the
combo, the
"calculating" delay occurs again.

The combo (along with 3 other exaclty similar combos) is on a
continuous
subform and only contains two fields
(AttendeeID and a Last/First concatenated field), and consists of only
825
items, sorted on Last/First. The ID is indexed NoDupes and key, and
Last/First are indexed DupesOK.
There is no criteria for the combo query. There is a NoShow True/False =
True field in the query

The PC is a 2Ghz P4 with 256K of memory, and we moved the FE/BE (DATA
and
PROG) files to the local drive C:... with no real difference compared to
PROG and DATA on the network server, or PROG local and DATA on the
server.
I have an exact copy of the FE and BE, and it runs just fine on my P4
2.8GHz 1GB of memory.

AutoName Correct is turned off in Options.

I can not find any problem with my table design, or the combo query.
825
records is just not much of a load!

Any suggestions would be greatly appreciated.

Thanks,
Al Camp

Klaatu,
I wanted to respond to you earlier today, but knew that you hadn't been
around the NG for a bit. I even looked for you on other more recent
responses, so I could "tag" on to you there.

I found the problem this morning...
I temporarily had the customer remove the 4 combos from the continuous
subform. Still had the calculating bug!
OK, then we removed the subform altogether. NO calculating!
To make a long story short... it was a Conditional Format field I had to
track how many people were signed up for a workshop. It used a DLookup to
calculate how many people had signed up for that workshop, and go Yellow
when within 10% of capacity, and red when Filled.
I deleted the CF conditions and voila... no calculating!
The DLookup still indicates the qty, but it was definitely the CF that
was causing the bug.
http://support.microsoft.com/?id=555033
I haven't tried the solutions... right now I just want the client to run
clean for a bit. I may not even retry the CF... it's not that critical,
because when they (on another form) assign workshops, they can't select a
workshop that has met it's max capacity
Thanks for hangin' in there. Thought you'd like to know the outcome.
--
hth
Al Camp
Candia Computer Consulting - Candia NH
http://home.comcast.net/~cccsolutions

"Klatuu" wrote in message
...
Doesn't look like it should be a problem.
Sorry to be so long getting back. I have been on a crunch time project
and
had to work all weekend to be prepared for this morning.

"Al Camp" wrote:

Klatuu,
Hope things are well with you...

Here's the query behind the combo...
SELECT tblAttendees.AttendeeID, [AttendeeLastName] & ", " &
[AttendeeFirstName] AS FullName FROM tblAttendees WHERE
(((tblAttendees.Active)=True)) ORDER BY [AttendeeLastName] & ", " &
[AttendeeFirstName];

Only one table involved...
It's really straight forward. For the life of me I can't figure this one
out. It works like a champ on my machine. And, I've built many apps
with
more "complicated" combo sources than this. (multiple tables, pass
thrus,
etc...)

Thanks for any assistance,
Al Camp

"Klatuu" wrote in message
...
4 * 825 = 3,300 - Each query will run independantly. Still, not a huge
number of records to search. There must be something in the query that
is
slowing it down. I do see you are concatenating the name which takes a
little extra time.

Could you post the row source for the queries so we can see if there is
anything that jumps out.



"Al Camp" wrote:

My client is getting a "calculating" indication in the status bar,
and
a
combo is taking 15 minutes to load. The cursor is frozen, Ctrl-Break
does
not stop the "Calculating".
Eventually, the "Calculating" goes away, and the combo works well.
If the client edits any records in the table that is the source
for
the
combo, the
"calculating" delay occurs again.

The combo (along with 3 other exaclty similar combos) is on a
continuous
subform and only contains two fields
(AttendeeID and a Last/First concatenated field), and consists of only
825
items, sorted on Last/First. The ID is indexed NoDupes and key, and
Last/First are indexed DupesOK.
There is no criteria for the combo query. There is a NoShow
True/False =
True field in the query

The PC is a 2Ghz P4 with 256K of memory, and we moved the FE/BE
(DATA
and
PROG) files to the local drive C:... with no real difference compared
to
PROG and DATA on the network server, or PROG local and DATA on the
server.
I have an exact copy of the FE and BE, and it runs just fine on my
P4
2.8GHz 1GB of memory.

AutoName Correct is turned off in Options.

I can not find any problem with my table design, or the combo
query.
825
records is just not much of a load!

Any suggestions would be greatly appreciated.

Thanks,
Al Camp

No problem, Al. Glad you found the problem. Sorry I haven't been around,
but this is our first Month End Load using a new system where we get our
data. I have been rewriting a boatload of code and queries to accomodate
different field names, data types, etc.

I seldom use CF for exactly this reason. It is invisible unless you know it
is there and, as you have seen, it can bite.

Rather than reintroduce CF, how about finding a good spot in your form to do
the formatting programmatically?

"Al Camp" wrote:

Klaatu,
I wanted to respond to you earlier today, but knew that you hadn't been
around the NG for a bit. I even looked for you on other more recent
responses, so I could "tag" on to you there.

I found the problem this morning...
I temporarily had the customer remove the 4 combos from the continuous
subform. Still had the calculating bug!
OK, then we removed the subform altogether. NO calculating!
To make a long story short... it was a Conditional Format field I had to
track how many people were signed up for a workshop. It used a DLookup to
calculate how many people had signed up for that workshop, and go Yellow
when within 10% of capacity, and red when Filled.
I deleted the CF conditions and voila... no calculating!
The DLookup still indicates the qty, but it was definitely the CF that
was causing the bug.
http://support.microsoft.com/?id=555033
I haven't tried the solutions... right now I just want the client to run
clean for a bit. I may not even retry the CF... it's not that critical,
because when they (on another form) assign workshops, they can't select a
workshop that has met it's max capacity
Thanks for hangin' in there. Thought you'd like to know the outcome.
--
hth
Al Camp
Candia Computer Consulting - Candia NH
http://home.comcast.net/~cccsolutions

"Klatuu" wrote in message
...
Doesn't look like it should be a problem.
Sorry to be so long getting back. I have been on a crunch time project
and
had to work all weekend to be prepared for this morning.

"Al Camp" wrote:

Klatuu,
Hope things are well with you...

Here's the query behind the combo...
SELECT tblAttendees.AttendeeID, [AttendeeLastName] & ", " &
[AttendeeFirstName] AS FullName FROM tblAttendees WHERE
(((tblAttendees.Active)=True)) ORDER BY [AttendeeLastName] & ", " &
[AttendeeFirstName];

Only one table involved...
It's really straight forward. For the life of me I can't figure this one
out. It works like a champ on my machine. And, I've built many apps
with
more "complicated" combo sources than this. (multiple tables, pass
thrus,
etc...)

Thanks for any assistance,
Al Camp

"Klatuu" wrote in message
...
4 * 825 = 3,300 - Each query will run independantly. Still, not a huge
number of records to search. There must be something in the query that
is
slowing it down. I do see you are concatenating the name which takes a
little extra time.

Could you post the row source for the queries so we can see if there is
anything that jumps out.



"Al Camp" wrote:

My client is getting a "calculating" indication in the status bar,
and
a
combo is taking 15 minutes to load. The cursor is frozen, Ctrl-Break
does
not stop the "Calculating".
Eventually, the "Calculating" goes away, and the combo works well.
If the client edits any records in the table that is the source
for
the
combo, the
"calculating" delay occurs again.

The combo (along with 3 other exaclty similar combos) is on a
continuous
subform and only contains two fields
(AttendeeID and a Last/First concatenated field), and consists of only
825
items, sorted on Last/First. The ID is indexed NoDupes and key, and
Last/First are indexed DupesOK.
There is no criteria for the combo query. There is a NoShow
True/False =
True field in the query

The PC is a 2Ghz P4 with 256K of memory, and we moved the FE/BE
(DATA
and
PROG) files to the local drive C:... with no real difference compared
to
PROG and DATA on the network server, or PROG local and DATA on the
server.
I have an exact copy of the FE and BE, and it runs just fine on my
P4
2.8GHz 1GB of memory.

AutoName Correct is turned off in Options.

I can not find any problem with my table design, or the combo
query.
825
records is just not much of a load!

Any suggestions would be greatly appreciated.

Thanks,
Al Camp

Klatuu,
I knew I would mispell your name eventually...
Klaatu,
I wanted to respond to you earlier today.....

Same here, as far as doing some heavy "fingerboning" on the PC this week.
I have 2 projects rolling out at once, so I'm pretty busy with client needs.
And, this bug set me back a bit...

This CF problem is really a "Don't whiz into the wind!" situation. That
field was only "informational" on that form anyway. It still shows for
example, 22 signed up vs. 25 capacity. The CF and associated "color" for
the field was just bells and whistles. I have only built 3 or 4 apps in
2003, so I thought I'd try out the CF. Well... I did, and so much for that!

The really important work occurs on a different "assigning" form,
where... if a class is full, it is no longer available for selection.
That's the important part, and that works just fine.

Thanks, and take care,
Al Camp
Candia Computer Consulting - Candia NH
http://home.comcast.net/~cccsolutions

"Klatuu" wrote in message
...
No problem, Al. Glad you found the problem. Sorry I haven't been around,
but this is our first Month End Load using a new system where we get our
data. I have been rewriting a boatload of code and queries to accomodate
different field names, data types, etc.

I seldom use CF for exactly this reason. It is invisible unless you know
it
is there and, as you have seen, it can bite.

Rather than reintroduce CF, how about finding a good spot in your form to
do
the formatting programmatically?

"Al Camp" wrote:

Klaatu,
I wanted to respond to you earlier today, but knew that you hadn't
been
around the NG for a bit. I even looked for you on other more recent
responses, so I could "tag" on to you there.

I found the problem this morning...
I temporarily had the customer remove the 4 combos from the continuous
subform. Still had the calculating bug!
OK, then we removed the subform altogether. NO calculating!
To make a long story short... it was a Conditional Format field I had
to
track how many people were signed up for a workshop. It used a DLookup
to
calculate how many people had signed up for that workshop, and go Yellow
when within 10% of capacity, and red when Filled.
I deleted the CF conditions and voila... no calculating!
The DLookup still indicates the qty, but it was definitely the CF that
was causing the bug.
http://support.microsoft.com/?id=555033
I haven't tried the solutions... right now I just want the client to
run
clean for a bit. I may not even retry the CF... it's not that critical,
because when they (on another form) assign workshops, they can't select a
workshop that has met it's max capacity
Thanks for hangin' in there. Thought you'd like to know the outcome.
--
hth
Al Camp
Candia Computer Consulting - Candia NH
http://home.comcast.net/~cccsolutions

"Klatuu" wrote in message
...
Doesn't look like it should be a problem.
Sorry to be so long getting back. I have been on a crunch time project
and
had to work all weekend to be prepared for this morning.

"Al Camp" wrote:

Klatuu,
Hope things are well with you...

Here's the query behind the combo...
SELECT tblAttendees.AttendeeID, [AttendeeLastName] & ", " &
[AttendeeFirstName] AS FullName FROM tblAttendees WHERE
(((tblAttendees.Active)=True)) ORDER BY [AttendeeLastName] & ", " &
[AttendeeFirstName];

Only one table involved...
It's really straight forward. For the life of me I can't figure this
one
out. It works like a champ on my machine. And, I've built many apps
with
more "complicated" combo sources than this. (multiple tables, pass
thrus,
etc...)

Thanks for any assistance,
Al Camp

"Klatuu" wrote in message
...
4 * 825 = 3,300 - Each query will run independantly. Still, not a
huge
number of records to search. There must be something in the query
that
is
slowing it down. I do see you are concatenating the name which
takes a
little extra time.

Could you post the row source for the queries so we can see if there
is
anything that jumps out.



"Al Camp" wrote:

My client is getting a "calculating" indication in the status
bar,
and
a
combo is taking 15 minutes to load. The cursor is frozen,
Ctrl-Break
does
not stop the "Calculating".
Eventually, the "Calculating" goes away, and the combo works
well.
If the client edits any records in the table that is the source
for
the
combo, the
"calculating" delay occurs again.

The combo (along with 3 other exaclty similar combos) is on a
continuous
subform and only contains two fields
(AttendeeID and a Last/First concatenated field), and consists of
only
825
items, sorted on Last/First. The ID is indexed NoDupes and key,
and
Last/First are indexed DupesOK.
There is no criteria for the combo query. There is a NoShow
True/False =
True field in the query

The PC is a 2Ghz P4 with 256K of memory, and we moved the FE/BE
(DATA
and
PROG) files to the local drive C:... with no real difference
compared
to
PROG and DATA on the network server, or PROG local and DATA on the
server.
I have an exact copy of the FE and BE, and it runs just fine on
my
P4
2.8GHz 1GB of memory.

AutoName Correct is turned off in Options.

I can not find any problem with my table design, or the combo
query.
825
records is just not much of a load!

Any suggestions would be greatly appreciated.

Thanks,
Al Camp

Well, here it is 20 minutes after quitting time and I am still waiting to see
if I can go. The bone heads in Virginia have not sent the "new and improved"
data so I can baby sit the first run of my stuff.

So, a thought, although it is not that important, patting clients on the
head can buy a lot. so I was thinking that you could manually do the
formatting once all the combos have finished.
Or, for some fun, I have a routine that randomly flashes the form and
control back colors. It is sort of like Access on LSD

"Al Camp" wrote:

Klatuu,
I knew I would mispell your name eventually...
Klaatu,
I wanted to respond to you earlier today.....

Same here, as far as doing some heavy "fingerboning" on the PC this week.
I have 2 projects rolling out at once, so I'm pretty busy with client needs.
And, this bug set me back a bit...

This CF problem is really a "Don't whiz into the wind!" situation. That
field was only "informational" on that form anyway. It still shows for
example, 22 signed up vs. 25 capacity. The CF and associated "color" for
the field was just bells and whistles. I have only built 3 or 4 apps in
2003, so I thought I'd try out the CF. Well... I did, and so much for that!

The really important work occurs on a different "assigning" form,
where... if a class is full, it is no longer available for selection.
That's the important part, and that works just fine.

Thanks, and take care,
Al Camp
Candia Computer Consulting - Candia NH
http://home.comcast.net/~cccsolutions

"Klatuu" wrote in message
...
No problem, Al. Glad you found the problem. Sorry I haven't been around,
but this is our first Month End Load using a new system where we get our
data. I have been rewriting a boatload of code and queries to accomodate
different field names, data types, etc.

I seldom use CF for exactly this reason. It is invisible unless you know
it
is there and, as you have seen, it can bite.

Rather than reintroduce CF, how about finding a good spot in your form to
do
the formatting programmatically?

"Al Camp" wrote:

Klaatu,
I wanted to respond to you earlier today, but knew that you hadn't
been
around the NG for a bit. I even looked for you on other more recent
responses, so I could "tag" on to you there.

I found the problem this morning...
I temporarily had the customer remove the 4 combos from the continuous
subform. Still had the calculating bug!
OK, then we removed the subform altogether. NO calculating!
To make a long story short... it was a Conditional Format field I had
to
track how many people were signed up for a workshop. It used a DLookup
to
calculate how many people had signed up for that workshop, and go Yellow
when within 10% of capacity, and red when Filled.
I deleted the CF conditions and voila... no calculating!
The DLookup still indicates the qty, but it was definitely the CF that
was causing the bug.
http://support.microsoft.com/?id=555033
I haven't tried the solutions... right now I just want the client to
run
clean for a bit. I may not even retry the CF... it's not that critical,
because when they (on another form) assign workshops, they can't select a
workshop that has met it's max capacity
Thanks for hangin' in there. Thought you'd like to know the outcome.
--
hth
Al Camp
Candia Computer Consulting - Candia NH
http://home.comcast.net/~cccsolutions

"Klatuu" wrote in message
...
Doesn't look like it should be a problem.
Sorry to be so long getting back. I have been on a crunch time project
and
had to work all weekend to be prepared for this morning.

"Al Camp" wrote:

Klatuu,
Hope things are well with you...

Here's the query behind the combo...
SELECT tblAttendees.AttendeeID, [AttendeeLastName] & ", " &
[AttendeeFirstName] AS FullName FROM tblAttendees WHERE
(((tblAttendees.Active)=True)) ORDER BY [AttendeeLastName] & ", " &
[AttendeeFirstName];

Only one table involved...
It's really straight forward. For the life of me I can't figure this
one
out. It works like a champ on my machine. And, I've built many apps
with
more "complicated" combo sources than this. (multiple tables, pass
thrus,
etc...)

Thanks for any assistance,
Al Camp

"Klatuu" wrote in message
...
4 * 825 = 3,300 - Each query will run independantly. Still, not a
huge
number of records to search. There must be something in the query
that
is
slowing it down. I do see you are concatenating the name which
takes a
little extra time.

Could you post the row source for the queries so we can see if there
is
anything that jumps out.



"Al Camp" wrote:

My client is getting a "calculating" indication in the status
bar,
and
a
combo is taking 15 minutes to load. The cursor is frozen,
Ctrl-Break
does
not stop the "Calculating".
Eventually, the "Calculating" goes away, and the combo works
well.
If the client edits any records in the table that is the source
for
the
combo, the
"calculating" delay occurs again.

The combo (along with 3 other exaclty similar combos) is on a
continuous
subform and only contains two fields
(AttendeeID and a Last/First concatenated field), and consists of
only
825
items, sorted on Last/First. The ID is indexed NoDupes and key,
and
Last/First are indexed DupesOK.
There is no criteria for the combo query. There is a NoShow
True/False =
True field in the query

The PC is a 2Ghz P4 with 256K of memory, and we moved the FE/BE
(DATA
and
PROG) files to the local drive C:... with no real difference
compared
to
PROG and DATA on the network server, or PROG local and DATA on the
server.
I have an exact copy of the FE and BE, and it runs just fine on
my
P4
2.8GHz 1GB of memory.

AutoName Correct is turned off in Options.

I can not find any problem with my table design, or the combo
query.
825
records is just not much of a load!

Any suggestions would be greatly appreciated.

Thanks,
Al Camp

Klatuu,
Well, I think removing the CF won't impact the client at all, so I'll
just let it go for now.
I developed a little subform (Access 97) that displays "machine repair"
order of priority in a large shop. The 1, 2, and 3 priorities blink red,
blank, red, blank every second, while all others lower priorities display as
blank.
Had some fun on that one!

If you do have a routine that will simulate CF in a continuous subform
I'd like to see that though.
Only if it's not a problem to do so...
You could use the Contact Me on my website. I know you're busy, so
please don't go to any trouble.
Thanks,
Al Camp
Candia Computer Consulting - Candia NH
http://home.comcast.net/~cccsolutions

"Klatuu" wrote in message
...
Well, here it is 20 minutes after quitting time and I am still waiting to
see
if I can go. The bone heads in Virginia have not sent the "new and
improved"
data so I can baby sit the first run of my stuff.

So, a thought, although it is not that important, patting clients on the
head can buy a lot. so I was thinking that you could manually do the
formatting once all the combos have finished.
Or, for some fun, I have a routine that randomly flashes the form and
control back colors. It is sort of like Access on LSD

"Al Camp" wrote:

Klatuu,
I knew I would mispell your name eventually...
Klaatu,
I wanted to respond to you earlier today.....

Same here, as far as doing some heavy "fingerboning" on the PC this
week.
I have 2 projects rolling out at once, so I'm pretty busy with client
needs.
And, this bug set me back a bit...

This CF problem is really a "Don't whiz into the wind!" situation.
That
field was only "informational" on that form anyway. It still shows for
example, 22 signed up vs. 25 capacity. The CF and associated "color" for
the field was just bells and whistles. I have only built 3 or 4 apps in
2003, so I thought I'd try out the CF. Well... I did, and so much for
that!

The really important work occurs on a different "assigning" form,
where... if a class is full, it is no longer available for selection.
That's the important part, and that works just fine.

Thanks, and take care,
Al Camp
Candia Computer Consulting - Candia NH
http://home.comcast.net/~cccsolutions

"Klatuu" wrote in message
...
No problem, Al. Glad you found the problem. Sorry I haven't been
around,
but this is our first Month End Load using a new system where we get
our
data. I have been rewriting a boatload of code and queries to
accomodate
different field names, data types, etc.

I seldom use CF for exactly this reason. It is invisible unless you
know
it
is there and, as you have seen, it can bite.

Rather than reintroduce CF, how about finding a good spot in your form
to
do
the formatting programmatically?

"Al Camp" wrote:

Klaatu,
I wanted to respond to you earlier today, but knew that you hadn't
been
around the NG for a bit. I even looked for you on other more recent
responses, so I could "tag" on to you there.

I found the problem this morning...
I temporarily had the customer remove the 4 combos from the
continuous
subform. Still had the calculating bug!
OK, then we removed the subform altogether. NO calculating!
To make a long story short... it was a Conditional Format field I
had
to
track how many people were signed up for a workshop. It used a
DLookup
to
calculate how many people had signed up for that workshop, and go
Yellow
when within 10% of capacity, and red when Filled.
I deleted the CF conditions and voila... no calculating!
The DLookup still indicates the qty, but it was definitely the CF
that
was causing the bug.
http://support.microsoft.com/?id=555033
I haven't tried the solutions... right now I just want the client
to
run
clean for a bit. I may not even retry the CF... it's not that
critical,
because when they (on another form) assign workshops, they can't
select a
workshop that has met it's max capacity
Thanks for hangin' in there. Thought you'd like to know the
outcome.
--
hth
Al Camp
Candia Computer Consulting - Candia NH
http://home.comcast.net/~cccsolutions

"Klatuu" wrote in message
...
Doesn't look like it should be a problem.
Sorry to be so long getting back. I have been on a crunch time
project
and
had to work all weekend to be prepared for this morning.

"Al Camp" wrote:

Klatuu,
Hope things are well with you...

Here's the query behind the combo...
SELECT tblAttendees.AttendeeID, [AttendeeLastName] & ", " &
[AttendeeFirstName] AS FullName FROM tblAttendees WHERE
(((tblAttendees.Active)=True)) ORDER BY [AttendeeLastName] & ", " &
[AttendeeFirstName];

Only one table involved...
It's really straight forward. For the life of me I can't figure
this
one
out. It works like a champ on my machine. And, I've built many
apps
with
more "complicated" combo sources than this. (multiple tables, pass
thrus,
etc...)

Thanks for any assistance,
Al Camp

"Klatuu" wrote in message
...
4 * 825 = 3,300 - Each query will run independantly. Still, not a
huge
number of records to search. There must be something in the
query
that
is
slowing it down. I do see you are concatenating the name which
takes a
little extra time.

Could you post the row source for the queries so we can see if
there
is
anything that jumps out.



"Al Camp" wrote:

My client is getting a "calculating" indication in the status
bar,
and
a
combo is taking 15 minutes to load. The cursor is frozen,
Ctrl-Break
does
not stop the "Calculating".
Eventually, the "Calculating" goes away, and the combo works
well.
If the client edits any records in the table that is the
source
for
the
combo, the
"calculating" delay occurs again.

The combo (along with 3 other exaclty similar combos) is on a
continuous
subform and only contains two fields
(AttendeeID and a Last/First concatenated field), and consists
of
only
825
items, sorted on Last/First. The ID is indexed NoDupes and key,
and
Last/First are indexed DupesOK.
There is no criteria for the combo query. There is a NoShow
True/False =
True field in the query

The PC is a 2Ghz P4 with 256K of memory, and we moved the
FE/BE
(DATA
and
PROG) files to the local drive C:... with no real difference
compared
to
PROG and DATA on the network server, or PROG local and DATA on
the
server.
I have an exact copy of the FE and BE, and it runs just fine
on
my
P4
2.8GHz 1GB of memory.

AutoName Correct is turned off in Options.

I can not find any problem with my table design, or the combo
query.
825
records is just not much of a load!

Any suggestions would be greatly appreciated.

Thanks,
Al Camp