Form Not Opening To DblClick Event Filter

[CharlesWhiteman]

I have a form "FrmEnquiryDesk" There is a double click event which should open form (which it does) FrmContactForm.

When I created the listbox on FrmEnquiryDesk I set it to store the EnquiryID so that on a DblClk event it would open the contact form to that ID.

The issue I cant seem to find an answer on is that when the dblclick event is triggered it is not opening the form to the enquiry id but rather just a dataless form. My event click code works in all my other Db's so I am baffled!

Example Db attached & any clues I'll be completely greatful.

 

[MarkK]

Your quotes are out of place. This ...

[FONT="Verdana"][SIZE="1"]DoCmd.OpenForm "FrmContactForm", , , "[EnquiryID]" = " & Me.LbEnquiryDesk, , acWindowNormal"[/SIZE][/FONT]

Evaluates to this ...

[FONT="Verdana"][SIZE="1"]DoCmd.OpenForm "FrmContactForm", , , False[/SIZE][/FONT]

because "[EnquiryID]" does not equal " & Me.LbEnquiryDesk, , acWindowNormal".

 

[wazz]

some more ideas in sample. i moved contact data to a new table plus some other things.

 

[CharlesWhiteman]

Thanks Guys. I've tested the code and it is correct:

DoCmd.OpenForm "FrmContactForm", , , "[EnquiryID]" = " & Me.LbEnquiryDesk, , acWindowNormal"

This produces the right value in the immediate window but still the form doesnt open to the correct filter

Thanks for the adjustments but they were not necessary / couldnt quite see the point of them??

Any assistance to the original issue I'll be most greeatful. It's really foxing me now!!

 

[Galaxiom]

If your syntax works it is because Access has managed to negotiate invalid syntax. I assure you there is a point to using correct statements.

Try this:

DoCmd.OpenForm "FrmContactForm", , , "[EnquiryID] = " & Me.LbEnquiryDesk, , acWindowNormal

The filter evaluates to:
[EnquiryID] = {The value of Me.LbEnquiryDesk}

And as normal is the default you can leave out the ending.

 

[CharlesWhiteman]

That could well be the case. Since my post used the following systax which works.

Debug.Print Me.LbEnquiryDesk
DoCmd.OpenForm "FrmContactForm", , , "[EnquiryID] = " & Me.LbEnquiryDesk, , acWindowNormal

Thanks, I'll have to compare the two in detail.

 

[Galaxiom]

That could well be the case. Since my post used the following systax which works.

Debug.Print Me.LbEnquiryDesk
DoCmd.OpenForm "FrmContactForm", , , "[EnquiryID] = " & Me.LbEnquiryDesk, , acWindowNormal

Thanks, I'll have to compare the two in detail.

Well actually you posted:

DoCmd.OpenForm "FrmContactForm", , , "[EnquiryID]" = " & Me.LbEnquiryDesk, , acWindowNormal"

which won't work for the reason lagbolt described.

Where I posted:

DoCmd.OpenForm "FrmContactForm", , , "[EnquiryID] = " & Me.LbEnquiryDesk, , acWindowNormal

which is what you now say you previously posted.

And BTW Debug.Print Me.LbEnquiryDesk
reveals only that value of your listbox and is not proof of your syntax.

 

[Galaxiom]

Thanks for the adjustments but they were not necessary / couldnt quite see the point of them??

I presume you are talking about the changes Wazz suggested in new.zip. I haven't looked at the suggestions but I checked out your original sample and I know the kinds of things Wazz would have done.

You need to learn about "the point of them" as you clearly don't understand normalisation.

 

[CharlesWhiteman]

Thanks for the comments. And yes if comments (and reasons) are suggested then am happy to take it form the experts who know better than me. Which would be grat and then one will be able to pass it on. However, I'm not into normalization for the sake of it. Tables, Columns and Rows are free of charge! Sometimes normalization for technical greatness does not always suit the requirements of the Db.

 

[MarkK]

[...] normalization [...] does not always suit the requirements of the Db.

Normalization describes a set of observable realities about how data systems work, and how they fail. Ignoring normalization in database design is like ignoring aerodynamics in aircraft design. Good luck with that.

 

[boblarson]

I'm not into normalization for the sake of it.

Are you "in" to getting data out without jumping through major hoops, running all sorts of union queries, and lots, and lots of coding? And, are you "in" to having data have integrity?

If so, then normalization IS for you. If not, then you might as well just use Excel to store and retrieve information. Normalized data structures are what give a relational database system its power.

Sometimes normalization for technical greatness does not always suit the requirements of the Db.

That is true to some extent. The majority of the time, some denormalization may be warranted for performance or some reporting issues. Data warehouse structures for reporting (not data input) are normally denormalized structures.

But, you must know when to denormalize and when not to, and the times of denormalization are definitely the EXCEPTION and not the rule.

 

[CharlesWhiteman]

Thanks Bob, AS I'm getting deeper into it I consider it a step forward to be answering these sort of issues. As I understand it, normalization is primarily about doing away with replicated data in numerous tables and conforming to various standards of normalization - I think to some extent is about vizualizing structure before building whereas I have tended to build and leaqrn in the process! Hmmm!