Can't edit ... bound to unknown field ...

[Jeff Boyce]

Access 2002, SP3, linked to SQL-Server 2000 back-end tables.

Added a couple "bit" fields to the underlying SQL-Server table, refreshed
the link, can see the added fields as "Yes/No" fields.

Checked the total bytes in the rows and they are under 200.

Can create a query to return rows with these new fields from the table --
the query is editable, I can change the values of these, save the row,
change the values back (and save the changes).

Have a form based on that query. All (as in ALL) other fields are editable,
including other Yes/No fields. But the two new fields in the back-end, now
visible (and editable) in the underlying query, are mysteriously missing in
action?!

Adding the query fields as text boxes, I get #Name.

Adding the query fields as checkboxes, I get grayed checkbox (looks like a
null).

Either approach gets me the Status Bar message "Can't edit ... bound to
unknow field named ..." and the name of the field I just pulled down from
the list of available fields?!?

DB has been compacted & repaired. The DB has been started over (imported
objects into new empty MDB). The /Decompile option has been exercised.
Still no joy.

Search of the newsgroups, Google, and Microsoft's KB have been unsuccessful
so far.

Anyone seen this before? Solutions?!

Thanks in advance.

Jeff Boyce

 

[Jeff Boyce]

One more wrinkle...

I "pulled down" a text field and a date/time field from the list of the
query's available fields. I was able to edit both of these. (These were
pre-existing fields, not newly added to SQL-Server.)

So it may be that the issue is with the Yes/No (bit) fields (but only the
newly-added ones, since the pre-existing ones work fine, thank you!)...

Thanks again for any leads.

Jeff Boyce

 

[John Vinson]

Have a form based on that query. All (as in ALL) other fields are editable,
including other Yes/No fields. But the two new fields in the back-end, now
visible (and editable) in the underlying query, are mysteriously missing in
action?!

Try opening the Form in design view; view its Recordsource property;
click the ... icon by it to open it in query design view; and make
sure the new fields are in fact part of the recordsource. If you add
new fields to a table (whether linked or local!) they frequently won't
show up until you do so.

John W. Vinson[MVP]

 

[Jeff Boyce]

Thanks, John.

Just to be sure, I deleted the form's source (the query that works), saved
the form, reopened it in design view, re-connected it to the query,
confirmed that the new fields show in the Field List, "pulled down" one of
the new fields, saved and closed.

When I reopened the form, the (new) control reads #Name ... and the query
still provides an updateable version.

This is most confusing, since the other fields/controls this query brings
are all updateable, both in the query and in the form. It's just these two
new fields that work in the query, but are "unknown" when I try to add a
control based on them.

Any other leads, anyone?!

Thanks.

Jeff Boyce

 

[John Vinson]

When I reopened the form, the (new) control reads #Name ... and the query
still provides an updateable version.

This is most confusing, since the other fields/controls this query brings
are all updateable, both in the query and in the form. It's just these two
new fields that work in the query, but are "unknown" when I try to add a
control based on them.

Any other leads, anyone?!

Ummm... Name Autocorrect turned off I presume...?

Maybe some subtle corruption: you've compacted & repaired I assume,
how about decompiling, or creating a new database and importing
everything?

John W. Vinson[MVP]

 

[Jeff Boyce]

Yes, yes, yes, yes, and yes. (or "check", "check", ...)

I'd leave this alone and just walk away, but the user/owner is fairly
insistent on having a way to check/flag a condition that will be visible on
the form for other users.

The most likely candidate at this point is some form of (form) corruption,
since it is possible to create a new form in another mdb and get that "new"
field to show properly in the form. And if I import that form-let into the
mdb file that contains the problem chi... er, form, the form-let works
correctly.

That pretty much leaves the form itself as the likely culprit, even though
the object has been imported, and the db decompiled, Compacted and Repaired,
etc.

Drat! I was hoping to be able to avoid having to rebuild the entire form
from scratch.

Thanks again for the review and ideas.

Regards

Jeff Boyce

 

[Joan Wild]

SaveAsText see if you can spot anything?

 

[Jeff Boyce]

Good idea! I'll give it a go...

Jeff

SaveAsText see if you can spot anything?