you welcome, Andrew ;) happy to help
have you read this?
Access Basics by Crystal (Bill Mosca's site)
http://thatlldoit.com
Free 100-page book that covers essentials in Access
~~~
> I'm using the German Version of Access.
here are some German Access sites:
Thomas Möller
http://www.Team-Moeller.de
Gunter Avenius
http://www.avenius.de
http://www.accessribbon.de
http://www.ribboncreator.de
Karl Donaubauer
www.donkarl.com
Gunter Avenius, Jens Schilling, and Peter Doering:
http://dbdev.org/
not sure what it says, but there is a Download page :)
your English is great!
Warm Regards,
Crystal
*
(: have an awesome day :)
*
--- On Mon, 8/29/11, acravenrohm wrote:
> 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 :-)
>
> --- Crystal <strive4peace> 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