Hi Crystal, Thanks for your ideas,
One thing I forgot to mention and the reason why I was a bit wooly about how I linked the Forms, is that I'm using the German Version of Access.
Yes, I was using the LinkMaster and LinkChild Fields in the design but this is the Link I removed, to no effect. I'm now setting the Recordsource in the subform (code behind) using a "WHERE" clause with the ArticleID as a number and not as a parameter like Forms!...!... (for example WHERE ArticleID = 1234) so there's no artificial Dependancy here.
There's nothing special/strange/difficult/clever in the Table design, there's not even a relational link between the two tables let alone one with referential integrity (a database designer would throw up his/her hands in horror.)
The Form_BeforeUpdate Event sets ChangeDate and ChangePers Fields but stopping it do this doesn't change the behaviour.
However... Your idea of stepping through the BeforeUpdate Event has brought the answer, thanks...
The BeforeUpdate Event doesn't get fired of course until the record is to be saved. Attempting to set the focus to the SubForm fires the BeforeUpdate Event and this routine, for some reason, sets the Cancel to true and silently stops the focus changing... dooohhhhh!!!!!!
So, just need to find out what the silent Cancel is *really* supposed to be preventing and, mystery solved. Thanks (again)
So, that's Many Thanks :-)
--- In MS_Access_Professionals@yahoogroups.com, Crystal <strive4peace2008@...> wrote:
>
> Hi Andrew,
>
> Are you linking with the LinkMasterFields and LinkChildFields properties? Or are you embedding criteria in the subform RecordSource?
>
> Is there anything in the table design that would prevent the record in the main table from being saved? Like maybe Required is true, a ValidationRule, or a bad default value on a field that is the foreign key to a relationship with referencial integrity?
>
> Do you have a form BeforeUpdate event?
>
> My guess is that the answer lies in the code (and/or macros) ... post the code behind the form. If macros are called, trace them and make a Word document with screen shots you can post.
>
> Click on a control and look at the EVENTS tab in the Properties window. If anything is there, click on the property value, and then click the Builder Button [...] that appears to the right.
>
>
> Warm Regards,
> Crystal
>
> Access Basics by Crystal (Bill Mosca's site)
> http://thatlldoit.com
> Free 100-page book that covers essentials in Access
>
> *
> (: have an awesome day :)
> *
>
>
> --- On Sat, 8/27/11, acravenrohm wrote:
>
>
> > This seems to be something changed
> > recently but perhaps I just didn't notice it before.
> >
> > In short, data changes on a form make (some) subforms
> > "locked".
> >
> > I have a (non-continuous) form that is based on a Table
> > linked from an SQL Table. The Table has an IDENT, that is
> > not used, and an ArticleID Field. A (continuous) Subform is
> > based on another Table holding prices also linked in from
> > SQL Server. Originally the subform was populated using the
> > usual linkin of the form properties so that access
> > automatically showed the prices for each article as the user
> > chose an article. All well and good and normal.
> >
> > On the subform there's a combobox to select the
> > price-gourp, a text box to enter the price and a button to
> > add these unbound values into the table (per VBA but this is
> > irrelevant.)
> >
> > I'm fairly sure this has worked since as long as I can
> > remember but now, it doesn't. As soon as the main form gets
> > dirty (any change in the bound article data) the subform is
> > "kind of" disabled. "Kind of" means that the subform looks
> > completely normal, no field is grey, the button is not
> > greyed, and as the mouse cursor moves over the textfield it
> > turns into the caret.� However, the combobox can't be
> > droppeddown, the textbox doesn't take the focus and the
> > button can't be pressed.
> >
> > Anyone know how to fix this?
> >
> > I thought, "OK, the problem is Access might think I'm
> > changing the key field and so stops anything bad happening
> > by deactivating the linked Subform." Unfortunately no.�
> > I removed the link between the two forms and used code to
> > ensure that the subform just shows the records from the
> > selected article and, no change.� The slightest change
> > in the Article form blocks the pricetable subform.
> >
> > Any ideas or links to knowledge *why* this is and how to
> > fix it?
> >
> > Many thanks in advance,
> > Andrew
> >
> >
>
Tidak ada komentar:
Posting Komentar