Form data entry locked out

N

NES

I set up a form to allow data entry, and it worked fine. I temporarily set it
to NOT allow data entry edits, etc. while working on something else.

Now when I reversed those setting, I still remain locked out when I try to
enter data in that form.

I've tried the obvious, of course. But it doesn't work. Thanks for any help
you may offer.
 
R

Rick Brandt

NES said:
I set up a form to allow data entry, and it worked fine. I
temporarily set it to NOT allow data entry edits, etc. while working
on something else.

Now when I reversed those setting, I still remain locked out when I
try to enter data in that form.

I've tried the obvious, of course. But it doesn't work. Thanks for
any help you may offer.

Aside from the settings of the form this is more often than not caused by the
form being bound to a query that does not allow editing of its result set. Have
you changed anything about the record source the form is bound to?
 
N

NES

Thanks for the reply, Rick.

You may indeed be correct, but I can't find the change. Fortunately, before
this showed up, I emailed a copy to someone, so I was able to grab the old
version and save it to a different directory. It still works. I don't
remember making any changes to either table or query which is associated with
that form. Changes I made, as nearly as I can recall, were cosmetic.

I have tried "transplanting" the working form into the new version, and
found that it stops working. So the cause must lie elsewhere. I'll next try
"transplanting" the table, then the Query, and see what happens. I'll let you
know if I'm successful.
Thanks.
 
R

Rick Brandt

NES said:
Thanks for the reply, Rick.

You may indeed be correct, but I can't find the change. Fortunately,
before this showed up, I emailed a copy to someone, so I was able to
grab the old version and save it to a different directory. It still
works. I don't remember making any changes to either table or query
which is associated with that form. Changes I made, as nearly as I
can recall, were cosmetic.

I have tried "transplanting" the working form into the new version,
and found that it stops working. So the cause must lie elsewhere.
I'll next try "transplanting" the table, then the Query, and see what
happens. I'll let you know if I'm successful.
Thanks.

Just open the form in desing view and click the build button [...] to the right
of the RecordSource property. That will take you into the designer for the
query or SQL statement that the form is using. Once there switch to datasheet
view and see if you can edit data. If not, then that is your problem, not the
form.
 
N

NES

Well, Rick, I copied the table, the query and the form over to the "new"
version and it still doesn't work. I was careful to check the control sources
and linkage after the transplants. I'm at a total loss.

There couldn't have been much change between them, so I'll just use to old
and start from there. Thanks very much.
 
N

NES

I did as you suggested, and was NOT able to make direct entries into the
datasheet view. I then copied the SQL view of the query that works, as well
as the one that doesn't into a Word document for side by side comparison.
THey are identical.

Oddly, about half an hour ago I got a message that I had set the database to
not allow it to open. It seemed to be a glitch, and I did open it. I did the
compact and repair routine. Haven't had that problem since.

Don't know where to go from here, but to use the old one. But I'd sure like
to know why this is happening.
--
Norm Shimmel
Butler, PA


Rick Brandt said:
NES said:
Thanks for the reply, Rick.

You may indeed be correct, but I can't find the change. Fortunately,
before this showed up, I emailed a copy to someone, so I was able to
grab the old version and save it to a different directory. It still
works. I don't remember making any changes to either table or query
which is associated with that form. Changes I made, as nearly as I
can recall, were cosmetic.

I have tried "transplanting" the working form into the new version,
and found that it stops working. So the cause must lie elsewhere.
I'll next try "transplanting" the table, then the Query, and see what
happens. I'll let you know if I'm successful.
Thanks.

Just open the form in desing view and click the build button [...] to the right
of the RecordSource property. That will take you into the designer for the
query or SQL statement that the form is using. Once there switch to datasheet
view and see if you can edit data. If not, then that is your problem, not the
form.
 
R

Rick Brandt

NES said:
I did as you suggested, and was NOT able to make direct entries into
the datasheet view. I then copied the SQL view of the query that
works, as well as the one that doesn't into a Word document for side
by side comparison. THey are identical.

Oddly, about half an hour ago I got a message that I had set the
database to not allow it to open. It seemed to be a glitch, and I did
open it. I did the compact and repair routine. Haven't had that
problem since.

Don't know where to go from here, but to use the old one. But I'd
sure like to know why this is happening.

Does the query use more than one table as inputs? Generally speaking such
queries are often not editable and even when they allow edits it is not always a
good idea unless you are careful and know what you are doing since edits
(especially deletes) might not be applied to the desired table.

You might have the Recordset Type property on the query that allows edits to
"Dynaset (Inconsistent Updates)" as opposed to tyhe default "Dynaset". This is
one way to make a query that doesn't allow updates into one that allows them.
Notice that the setting sounds a little dangerous. That's because it can be as
I noted above.
 
N

NES

Thank Rick, I haven't done anyting with the "Dynaset" parameter.

There are two tables attached to this query. THe Medication Stores Table,
and the Restock Meds Update table. The first of the two supplies the NDC
number as well as the Med (record) number. The second table holds the new
data from the form such as quantity to add, total cost (to get LIFO unit
price).

The update query does the calculation of the new unit price, and posts the
other two items plus a date. This update query is not part of the problem at
all.

Here's a look at the SQL code for the Query with the problem...

SELECT [MEDICATION STORES TABLE].[Med Number], [MEDICATION STORES
TABLE].[NDC Number], [MEDICATION STORES TABLE].[Name Strength form], [Restock
Meds Update Table].[Plus Quantity], [Restock Meds Update Table].[Total
Price], [Restock Meds Update Table].Date
FROM [MEDICATION STORES TABLE] LEFT JOIN [Restock Meds Update Table] ON
[MEDICATION STORES TABLE].[Med Number] = [Restock Meds Update Table].[Med
Number]
ORDER BY [MEDICATION STORES TABLE].[NDC Number]
WITH OWNERACCESS OPTION;

It looks straightforward to me, but I'm not an SQL expert. I can read it,
but I can't speak it as the saying goes.

I really do appreciate the time you have taken with this.
 
N

NES

Rick, I found the problem.

Thanks to my infernal tinkering, the MEDICATION STORES table originally had
the key index on the Med Number (record number). However in trying to get a
dropdown search box (and other items) to list the med in order by NDC number,
I changed the key field to the NDC number. Having done so, that field changed
to Duplicates allowed without my having noticed it. I assure you I didn't
make that change myself. Once that was corrected to no duplicates allowed, it
works.

Sorry to have put you through this. I hope all of this helps others. Thanks
again.
 

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