A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Using Forms
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Inconsistent Form_Open behaviour



 
 
Thread Tools Display Modes
  #1  
Old December 14th, 2009, 12:33 AM posted to microsoft.public.access.forms
.Len B
external usenet poster
 
Posts: 81
Default Inconsistent Form_Open behaviour

I'm all out of ideas on this so I'm hoping someone might have a

suggestion of where to look next or what to try. It's a simple

concept but long-winded to describe.



I have an Access (2003) database. Of interest are 2 forms.



The first, frmChooseChild, loads at start-up and is used to call

the second form with a chosen record displayed.

It is a continuous form and begins by showing all records.

RecordSource=Child (linked table 618 records).

DataEntry=No, OnLoad runs routines which filters the RecordSet

progressively as the user types.

I am using the technique described here.

http://allenbrowne.com/AppFindAsUType.html

Each record row finishes with cmdChoose whose Click event runs

this code

stDocName = "Debug message:" & vbCrLf & "ChildID is "

MsgBox stDocName & ChildID, vbOKOnly, "DEBUGGING"



stDocName = "frmEnterNotes"

stLinkCriteria = "ChildID = " & ChildID

DoCmd.OpenForm stDocName, , , stLinkCriteria (breakpoint)



The second, frmEnterNotes, is in single form view.

RecordSource=selqEnterNotes, selected fields from same linked

table (partial SQL below). The only reason for not using the

table is RegionID3 and ORDER BY clause.



SELECT ChildID, FamilyNum, Surname, GivenNames, Address, _

Suburb, Postcode, other fields too.

FROM Child

WHERE (((Child.RegionID)3))

ORDER BY Child.Surname;



The problem, It works perfectly about 50% of the time. I can't detect

a pattern or why. I filter frmChooseChild to say 5 records then click

one of the cmdChoose buttons.



The debug MsgBox always confirms the correct ChildID no matter which of

the 5 I click on.

The stLinkCriteria always looks ok (watch window) e.g. "ChildID = 641"

but sometimes the new form opens with Autonumber in the ChildID field

(normally invisible) and the other fields either blank or showing default

values. (AddNew ?) The behaviour is consistent for a given ChildID.

However, the form's Filter property is always properly set to

ChildID = nnn, even when blank and AllowFilters is always Yes.



Hints, please.


--
Len
__________________________________________________ ____
remove nothing for valid email address.


  #2  
Old December 14th, 2009, 02:40 AM posted to microsoft.public.access.forms
.Len B
external usenet poster
 
Posts: 81
Default Inconsistent Form_Open behaviour

Found it!!
The ones that failed were Regions 3 or greater.
--
Len
__________________________________________________ ____
remove nothing for valid email address.
".Len B" wrote in message
...
| I'm all out of ideas on this so I'm hoping someone might have a
|
| suggestion of where to look next or what to try. It's a simple
|
| concept but long-winded to describe.
|
|
|
| I have an Access (2003) database. Of interest are 2 forms.
|
|
|
| The first, frmChooseChild, loads at start-up and is used to call
|
| the second form with a chosen record displayed.
|
| It is a continuous form and begins by showing all records.
|
| RecordSource=Child (linked table 618 records).
|
| DataEntry=No, OnLoad runs routines which filters the RecordSet
|
| progressively as the user types.
|
| I am using the technique described here.
|
| http://allenbrowne.com/AppFindAsUType.html
|
| Each record row finishes with cmdChoose whose Click event runs
|
| this code
|
| stDocName = "Debug message:" & vbCrLf & "ChildID is "
|
| MsgBox stDocName & ChildID, vbOKOnly, "DEBUGGING"
|
|
|
| stDocName = "frmEnterNotes"
|
| stLinkCriteria = "ChildID = " & ChildID
|
| DoCmd.OpenForm stDocName, , , stLinkCriteria (breakpoint)
|
|
|
| The second, frmEnterNotes, is in single form view.
|
| RecordSource=selqEnterNotes, selected fields from same linked
|
| table (partial SQL below). The only reason for not using the
|
| table is RegionID3 and ORDER BY clause.
|
|
|
| SELECT ChildID, FamilyNum, Surname, GivenNames, Address, _
|
| Suburb, Postcode, other fields too.
|
| FROM Child
|
| WHERE (((Child.RegionID)3))
|
| ORDER BY Child.Surname;
|
|
|
| The problem, It works perfectly about 50% of the time. I can't detect
|
| a pattern or why. I filter frmChooseChild to say 5 records then click
|
| one of the cmdChoose buttons.
|
|
|
| The debug MsgBox always confirms the correct ChildID no matter which of
|
| the 5 I click on.
|
| The stLinkCriteria always looks ok (watch window) e.g. "ChildID = 641"
|
| but sometimes the new form opens with Autonumber in the ChildID field
|
| (normally invisible) and the other fields either blank or showing
default
|
| values. (AddNew ?) The behaviour is consistent for a given ChildID.
|
| However, the form's Filter property is always properly set to
|
| ChildID = nnn, even when blank and AllowFilters is always Yes.
|
|
|
| Hints, please.
|
|
| --
| Len
| __________________________________________________ ____
| remove nothing for valid email address.
|
|



  #3  
Old December 29th, 2009, 05:37 AM posted to microsoft.public.access.forms
external usenet poster
 
Posts: n/a
Default Inconsistent Form Open behavior



".Len B" wrote in message
...
I'm all out of ideas on this so I'm hoping someone might have a

suggestion of where to look next or what to try. It's a simple

concept but long-winded to describe.



I have an Access (2003) database. Of interest are 2 forms.



The first, frmChooseChild, loads at start-up and is used to call

the second form with a chosen record displayed.

It is a continuous form and begins by showing all records.

RecordSource=Child (linked table 618 records).

DataEntry=No, OnLoad runs routines which filters the RecordSet

progressively as the user types.

I am using the technique described here.

http://allenbrowne.com/AppFindAsUType.html

Each record row finishes with cmdChoose whose Click event runs

this code

stDocName = "Debug message:" & vbCrLf & "ChildID is "

MsgBox stDocName & ChildID, vbOKOnly, "DEBUGGING"



stDocName = "frmEnterNotes"

stLinkCriteria = "ChildID = " & ChildID

DoCmd.OpenForm stDocName, , , stLinkCriteria (breakpoint)



The second, frmEnterNotes, is in single form view.

RecordSource=selqEnterNotes, selected fields from same linked

table (partial SQL below). The only reason for not using the

table is RegionID3 and ORDER BY clause.



SELECT ChildID, FamilyNum, Surname, GivenNames, Address, _

Suburb, Postcode, other fields too.

FROM Child

WHERE (((Child.RegionID)3))

ORDER BY Child.Surname;



The problem, It works perfectly about 50% of the time. I can't detect

a pattern or why. I filter frmChooseChild to say 5 records then click

one of the cmdChoose buttons.



The debug MsgBox always confirms the correct ChildID no matter which of

the 5 I click on.

The stLinkCriteria always looks ok (watch window) e.g. "ChildID = 641"

but sometimes the new form opens with Autonumber in the ChildID field

(normally invisible) and the other fields either blank or showing default

values. (AddNew ?) The behaviour is consistent for a given ChildID.

However, the form's Filter property is always properly set to

ChildID = nnn, even when blank and AllowFilters is always Yes.



Hints, please.


--
Len
__________________________________________________ ____
remove nothing for valid email address.


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 09:20 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.