"Recordset is not updateable"

S

short

I have a form with subforms, and when I try to delete/edit the subforms/
linked tables on the status bar it displays Recordset is not updateable.

I found on a site that the cause could be that the linked table might not
have a primary key or a unique index.

If all the tables have the same exact primary key is that what may be
causing this? So if that is, do I need to change every tables PK in order to
have this work?

Or I could not have the permissions to update subforms. (Which I'm trying to
see if I can get those permissions)

Thanks..
 
G

Golfinray

See if the query or table the subform is based on is editable (has the arrow
and asterisk at the bottom.) If the query or table is not editable, the
subform won't be either.
 
A

a a r o n _ k e m p f

In Access-- you're just kinda stuck with this chipmunk that randomly
throws up his arms and goes on strike.

if you were just using SQL Server, then you could utilize a couple of
tools to help you to make the query updateable

a) the uniqueTable property of the form
b) a special flavor of triggers called 'INSTEAD OF TRIGGERS'.

You would have both options-- if you just moved to SQL Server.

With Jet, you've got a flaky chipmunk that likes to go on strike
 
S

short

Just the table and queries that they are based on have the arrow and asterisk
(able to press) on the bottom in just table/query view. But on the subform
the arrow and asterisk is not able to press in (if that makes sense)
 
G

Golfinray

Try to delete or add a record on the mainform and see if it deletes on the
subform. If not, you may have a problem of linking between main and subforms.
If your query or table is editable, that should not be the problem.
 
J

John W. Vinson/MVP

I have a form with subforms, and when I try to delete/edit the subforms/
linked tables on the status bar it displays Recordset is not updateable.

I found on a site that the cause could be that the linked table might not
have a primary key or a unique index.

If all the tables have the same exact primary key is that what may be
causing this? So if that is, do I need to change every tables PK in order to
have this work?

Or I could not have the permissions to update subforms. (Which I'm trying to
see if I can get those permissions)

Thanks..

Having multiple tables all with the *SAME* primary key is almost
certainly an incorrect design. You don't need to change the value of
the tables' pk; but each table should have its own, distinct PK.

What are these tables? How are they related, if at all? What real life
entity do they represent? What is the Form's Recordsource property (if
it's a query, please post the SQL).
 
A

a a r o n _ k e m p f

I actually think that a one to one relationship is _VASTLY_ underused.

frequently if 12 different departments each have 3 different fields
for their departmet info-- it would inherently be 'more efficient' to
have this as 12 different tables (because people will typically only
ever query against 3 columns (their department) at the same time.

with a careful attention to detail-- one to one relationships can
increase performance incredibly.

-Aaron
 
L

Larry Linson

a a r o n _ k e m p f said:
I actually think that a one to one relationship is _VASTLY_ underused.
frequently if 12 different departments each have
3 different fields for their departmet info-- it would
inherently be 'more efficient' to have this as 12 different
tables (because people will typically only ever query
against 3 columns (their department) at the same time.

If you mean a single record has 3 fields of data for each of 12 different
departments, that is already a violation of relational database design
principles and that is what should be corrected. "Correcting" it by
creating 12 tables, the table itself identifying which department, is an
even further departure from relational design principles, and will cause
grief and pain in the future when trying to utilize the data.

I'd have expected a certified data base administrator to know those
principles and recognize such a situation, Mr. Kempf.
with a careful attention to detail-- one to one relationships
can increase performance incredibly.

Larry Linson
Microsoft Office Access MVP
 
P

Please Learn to Read

In the microsoft.public.access, you're just kinda stuck with this vicious
talking weasel who has only one answer to any problem "use SQL Server" (at
times, even after the original poster has indicated they _already_ "use SQL
Server"). Often, people here wish, hope, and pray that he will "throw up his
arms and go on strike".

Not even remotely did the original post imply the user wanted to know "if I
were going to convert to a server DB back end, which, in your opinion, would
be the one I should use." The question dealt with recordsets that updateable
and not updateable in Microsoft Access, and that, most often is a problem
that is realatively easy to solve in Microsoft Access, as others are pointing
out. The solution for minor problems, easy to solve in Access, is NEVER to
"switch to a server database back-end" (with its accompanying costs of
administration and maintenance, even if one uses a "free" version).

You will find the appropriate newsgroup for discussions about wildlife in
the USENET newsgroup heirarchy.

Please learn to read. Remedial reading courses are often offered free if you
cannot afford to pay, or inexpensively, at local social services agencies,
high schools, and community colleges.
 
A

a a r o n _ k e m p f

you're pretty sad if you don't know what a one to one is.
having accoutning data and payroll data in different tables-- at the
same grain.

it's not so complex.

of course-- if your database reporting engine supported drilldown--
you might know what I talk about when I say 'grain'.
 
A

a a r o n _ k e m p f

nothing wrong with me.

I just don't think that I should have people following me around-
attacking everything I say.

9 problems out of 10 can be solved by moving to SQL Server
 
B

BruceM

Why not move there, then? That would solve a big problem here.

nothing wrong with me.

I just don't think that I should have people following me around-
attacking everything I say.

9 problems out of 10 can be solved by moving to SQL Server
 
G

George Hepworth

All 9 of which are spelled "Aaron Kempf".


....
9 problems out of 10 can be solved by moving to SQL Server
 
S

So Sorry For Poor Aaron

a a r o n _ k e m p f said:
of course-- if your database reporting engine supported drilldown--
you might know what I talk about when I say 'grain'.

He may be pretty naive, but you and I know what 'grain' is, don't we,
sweetie?

I'll just explain it for him: It's when Big Bruce, Big Bubba, and Big Barney
run out of lube or get too hot to wait to find it.

I guess it does have something to do with "drilldown".

How come you wanna bring that up, pussybaby? You getting lonesome? The Big
boys are really hot to see you. "Hurry back, honey," they say.
 
S

So Sorry For Poor Aaron

George Hepworth said:
All 9 of which are spelled "Aaron Kempf".

Hey, Georgie,

you givin him way too much respect -- that's aaron kempf, lower case.

lyin, sleazy, lazy, dumbass jailbirds don deserve no capital letters.

he spend time in stir wif them big boys til his mouthpiece bail him out.

he lie bout pleadin guilty.

he only certified as a Certified Useless Newsgroup Troll a ****...

that other guy right, aaron don kno nuttin.
 
A

a a r o n _ k e m p f

I didn't lie about anything. Unlike most of the other people on this
group-- I always tell the truth.

Get the facts straight.

Just because a handful of retards in this group-- don't have the
mental capacity to learn SQL Server-- that doesn't mean that you need
to get stuck making $12/hour.
 

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