slightwv (䄆 Netminder)
asked on
Access 2007 Nested Tables
I have to develop a database on a system where my development options are pretty restricted. I have Access 2007 as my database so decided to use Access Forms for the GUI.
I believe my only other option is a .Net Winform.
This needs to be multi-user so I know I need to separate the GUI from the database.
The problem is, I didn't develop the GUI with linked tables thinking everything is basically 'the same'.
The form I developed includes a datasheet table object. It has a nested table and provides the '+' to expand to add/edit/delete child records.
I've attached a simple parent/child database to demonstrate this if I've used the wrong terminology. If you open the Parent table in datasheet view, you can expand to see the child rows.
Once you create a new database and link to the parent, you can no longer expand.
I didn't realize that I would lose this functionality when I moved to a linked table.
I'm hoping there is a work-around to this without migrating to continuous forms. I would like to keep datasheet so I don't have to rework a lot of the app.
junk.accdb
I believe my only other option is a .Net Winform.
This needs to be multi-user so I know I need to separate the GUI from the database.
The problem is, I didn't develop the GUI with linked tables thinking everything is basically 'the same'.
The form I developed includes a datasheet table object. It has a nested table and provides the '+' to expand to add/edit/delete child records.
I've attached a simple parent/child database to demonstrate this if I've used the wrong terminology. If you open the Parent table in datasheet view, you can expand to see the child rows.
Once you create a new database and link to the parent, you can no longer expand.
I didn't realize that I would lose this functionality when I moved to a linked table.
I'm hoping there is a work-around to this without migrating to continuous forms. I would like to keep datasheet so I don't have to rework a lot of the app.
junk.accdb
I found an example of a master/detail continuous form that might give you a head start if you decide to pursue that path.
http://www.blueclaw-db.com/download/master-detail_continuous_forms.htm
http://www.blueclaw-db.com/download/master-detail_continuous_forms.htm
ASKER
>>Access is a poor choice for n-tier development
Preaching to the choir. Trust me, I know this. But design time sure beats .Net Winforms...
>>This is called the sub-datasheet feature
Thanks for the name!
>>put a form in datasheet view within a main form, but I don't know if it retains the subdatasheet feature as I've never tried it
You can. That is what I ended up doing. The design basically has a parent, child, grandchild relationship. The main form shows a single parent record. Then I used the datasheet to show the many children and many grandchildren.
I didn't like how continous forms pulled this off. I found the work-around mentioned above where you placed the sub form in the page footer and as you moved through the child, the grandchild form would refresh.
It made a VERY ugly form.
Preaching to the choir. Trust me, I know this. But design time sure beats .Net Winforms...
>>This is called the sub-datasheet feature
Thanks for the name!
>>put a form in datasheet view within a main form, but I don't know if it retains the subdatasheet feature as I've never tried it
You can. That is what I ended up doing. The design basically has a parent, child, grandchild relationship. The main form shows a single parent record. Then I used the datasheet to show the many children and many grandchildren.
I didn't like how continous forms pulled this off. I found the work-around mentioned above where you placed the sub form in the page footer and as you moved through the child, the grandchild form would refresh.
It made a VERY ugly form.
ASKER
Here is a more realistic example of what I'm doing. With attached database and form.
The parent record is displayed in the form. It can have many child records and each child can have many children.
The sub-datasheet doesn't make the prettiest GUI but it is better than any alternative I have stumbled across.
junk.accdb
The parent record is displayed in the form. It can have many child records and each child can have many children.
The sub-datasheet doesn't make the prettiest GUI but it is better than any alternative I have stumbled across.
junk.accdb
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Queries solved the issue
Just a forewarning; Access is a poor choice for n-tier development, because basically, you can't to it.
<<I've attached a simple parent/child database to demonstrate this if I've used the wrong terminology. If you open the Parent table in datasheet view, you can expand to see the child rows.>>
This is called the sub-datasheet feature and usually with an Access app, you turn it off because it's a performance hog.
<<I'm hoping there is a work-around to this without migrating to continuous forms. I would like to keep datasheet so I don't have to rework a lot of the app.>>
There are probably some 3rd party grid controls that would allow you to do this, but with native Access controls, a main /subform cobination is it, which was design to directly express the parent / child relationship.
You can BTW put a form in datasheet view within a main form, but I don't know if it retains the subdatasheet feature as I've never tried it. Datasheets in the past have been limited in what you could do with them, lacking a number of events that a normal form would have.
A tree view control would come close, but it's really not designed to deal with whole records.
Jim.