Well, I am English, working in Germany, and I do occasionally browse the various Access Developer sites.
One more for your list of German sites, http://www.access-im-unternehmen.de/ where André Minhorst does some pretty incredible things with Access.
The application where I had the Problem has grown from its original Access 2.0 roots through Access 2000 into Access 2007 and as a result, there are some "fairy tale" pieces of code in there, fairy tale as in "once upon a time there was a customer problem and the big bad wolf solved it by ..." so sometimes I come up against a strange behaviour that is, as in this case, a side effect of the wrong use of an Access Method/Event in order to solve some problem. This time I thought of crying "wolf!" and sure enough, help came when I needed it :-)
--- In MS_Access_Professionals@yahoogroups.com, Crystal <strive4peace2008@...> wrote:
>
> 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