SomeoneHadBlundered
New member
- Local time
- Today, 15:12
- Joined
- Aug 7, 2012
- Messages
- 4
Hello y'all.
First post. W00t.
I have spent the last few days (approximately 22 hours) attempting to get combo-boxes to work on my form.
Yes - it seems almost impossible. Am I stupid? I have to ask myself. Or perhaps I'm caught up in some disturbing dream which involves a permanent cycle of catch-try statements that really needs a break. Sorry... this is VBA, isn't it?
Anyhoo: my database is looking quite nice. Quite a few many-to-many relationships though. I hadn't quite realised how much of a disaster many-to-many relationships would prove when making the frontend (i.e. the forms).
But sorry, I digress.
The combo-box situation has driven me near crazy. I have consulted many pages, even asked the advice of the best Access minds on StackOverflow, and nothing has surfaced that has so far worked. Have a go if you think you're hard enough, but you've been warned!
But let's chase back along the winding path whence this tale began. The dream was the creation of a scheduling system through Access 2010. You know, quite a straightforward thing. Quite intuitive.
Scheduling system? Well you'll need to make meetings. And who will you have meetings with? Has to have a table for contacts. Who are these contacts... this is a scheduling system for a business.. so it stands to reason that the contacts must be connected with businesses as well. And what about if the meeting is not with one person, but a whole department? That has to be accommodated. Then, you have to know who it is will be chairing this meeting (it takes two to tango!). Wouldn't it be nice if our company members could share this scheduling system on... Sharepoint! Then we could see who will be taking what meetings, and at what times... OH MY GOD! All our employees use Outlook... so you could integrate the meetings with the Outlook calendar. The possibilities are endless! Microsoft has provided the ambrosia of organisation!
Forms
Forms
Forms
Forms
Forms
:banghead:
There is no point having a form for meetings if you cannot select the contact that will be met! It is unreasonable to suppose that whoever is using the form will somehow remember the autogenerated ID integer of the business, or the client, or will be prepared to write up some half baked information in the meeting form about the client which is to be completed in the client form. Whilst filling in details in one table from a form designed for a different table may have some merits, the primary means by which the appointments - the entire crux upon which this database is based - must operate is by being able to select items from other tables through the use of combo boxes.
Oh god the combo boxes. They seem to mock me. They have even, on occasion, actually displayed the relevant information in the drop down menu (generally they refuse to do anything on the grounds that the "Control can't be edited; it's bound to the AutoNumber field ID" - well DUH, the control source is a key! God-damn.)
I've even followed the advice given here; (can't post links) to the letter, but nope; Access is having none of that nonsense!
I've started pulling the database apart; changing keys from Autogenerated numbers to String based names; dumbing down the architecture and reducing the relationships. But still - still - the meeting form refuses even the vestiges of common sense or usability. My next option will be to remove many-to-many relationships altogether. I'm pretty sure that that will work, although it will make the Scheduling system only a fine line above useless.
Any attempts to defeat the combo box problem will be rewarded in heaven (good deeds, don't ya know?)
http
://w
ww.
ucd.ie/fencing/Images/shed_databa
se.P
NG (how hard is it to disguise LINKS!!?!?!?!)
For the record I've used pretty much every permutation I can think of to make the combobox work... it would take a bit of time to list everything I've tried (looking at the navigation menu I see that I've got 14 Meeting forms still in operation... after all the previous ones that have now been deleted)...
First post. W00t.
I have spent the last few days (approximately 22 hours) attempting to get combo-boxes to work on my form.
Yes - it seems almost impossible. Am I stupid? I have to ask myself. Or perhaps I'm caught up in some disturbing dream which involves a permanent cycle of catch-try statements that really needs a break. Sorry... this is VBA, isn't it?
Anyhoo: my database is looking quite nice. Quite a few many-to-many relationships though. I hadn't quite realised how much of a disaster many-to-many relationships would prove when making the frontend (i.e. the forms).
But sorry, I digress.
The combo-box situation has driven me near crazy. I have consulted many pages, even asked the advice of the best Access minds on StackOverflow, and nothing has surfaced that has so far worked. Have a go if you think you're hard enough, but you've been warned!
But let's chase back along the winding path whence this tale began. The dream was the creation of a scheduling system through Access 2010. You know, quite a straightforward thing. Quite intuitive.
Scheduling system? Well you'll need to make meetings. And who will you have meetings with? Has to have a table for contacts. Who are these contacts... this is a scheduling system for a business.. so it stands to reason that the contacts must be connected with businesses as well. And what about if the meeting is not with one person, but a whole department? That has to be accommodated. Then, you have to know who it is will be chairing this meeting (it takes two to tango!). Wouldn't it be nice if our company members could share this scheduling system on... Sharepoint! Then we could see who will be taking what meetings, and at what times... OH MY GOD! All our employees use Outlook... so you could integrate the meetings with the Outlook calendar. The possibilities are endless! Microsoft has provided the ambrosia of organisation!
Forms
Forms
Forms
Forms
Forms
:banghead:
There is no point having a form for meetings if you cannot select the contact that will be met! It is unreasonable to suppose that whoever is using the form will somehow remember the autogenerated ID integer of the business, or the client, or will be prepared to write up some half baked information in the meeting form about the client which is to be completed in the client form. Whilst filling in details in one table from a form designed for a different table may have some merits, the primary means by which the appointments - the entire crux upon which this database is based - must operate is by being able to select items from other tables through the use of combo boxes.
Oh god the combo boxes. They seem to mock me. They have even, on occasion, actually displayed the relevant information in the drop down menu (generally they refuse to do anything on the grounds that the "Control can't be edited; it's bound to the AutoNumber field ID" - well DUH, the control source is a key! God-damn.)
I've even followed the advice given here; (can't post links) to the letter, but nope; Access is having none of that nonsense!
I've started pulling the database apart; changing keys from Autogenerated numbers to String based names; dumbing down the architecture and reducing the relationships. But still - still - the meeting form refuses even the vestiges of common sense or usability. My next option will be to remove many-to-many relationships altogether. I'm pretty sure that that will work, although it will make the Scheduling system only a fine line above useless.
Any attempts to defeat the combo box problem will be rewarded in heaven (good deeds, don't ya know?)
http
://w
ww.
ucd.ie/fencing/Images/shed_databa
se.P
NG (how hard is it to disguise LINKS!!?!?!?!)
For the record I've used pretty much every permutation I can think of to make the combobox work... it would take a bit of time to list everything I've tried (looking at the navigation menu I see that I've got 14 Meeting forms still in operation... after all the previous ones that have now been deleted)...
