How's This SubForm Thing Done?

[abrogard]

I've got a couple of problems with this SubForm idea for one to many tables. Could someone tell me if I've got it right or wrong:



I have a many to many with a junction table in between.

Required: A form to input data. One new record to the 'one' table and many (4,5,6) to the 'many' table.

Method: Create a form on the 'one' table.
Create a form on the 'many' table.
Make the 'many' form a subform of the 'one'.

Is that right?

Now the couple of queries arising from that assuming it is right:

1. How do I get rid of the 'form header' on the subform? I don't see any reason for that to be there.

2. How is it going to receive more than one input, the subform, I mean, how is it going to intake more than one item? Will it just do that? The two-form system will work as is and not close or go to another record on the 'one' table before all the records on the 'many' table have been done. Right?

This is all system created. Not hand coded. I just click the wizards or whatever. Is this the way it's done or have I got it wrong?

p.s. A LATER EDIT.

I am extraordinarily stupid and lazy aren't I? I could have tried it before I came here troubling you good people.
Well I did try it just now and it works like magic. We get a control bar (or whatever you call it) for each form and can just keep adding to the subform until satisfied. I went to the table view and checked the tables and it is all there.

Good-oh.

So now I just wonder about the Form Header thing. And a new question. This system generated thing will let the user delete records and do what they like, I suppose. It is to avoid that sort of thing that we resort to creating our own forms in the first place.

So if I want full control over what the user can input and change/delete can I modify these forms to suit or must I take a completely different approach - coding my own input forms completely?

[June7]

In Design View, right click on the form header and toggle off the Form Header/Footer.

You may edit the forms. I don't use the form and report build wizards because they do things I don't like, such as 'grouping' the controls which are harder to modify. Select all the controls and right click > Layout > Remove Layout. Now the controls can be moved and resized as you wish. Wizards might also create macro code. I don't use macros, only VBA.

[abrogard]

Thank you for those hints.

I guess what you're probably saying to me is that I should write my own forms.

I thought that might be it.

I don't just want to edit the forms a little I want a different interface for the user. Almost. I think.

Like I don't want that little 'control bar' or whatever it is called with the arrows for going back and forward etc. I want a control button or something with instructions 'next' or 'add another', that kind of thing.

If I want to write the whole things myself how much help can I get from the existing setup? Like is there 'wizard' generated code there I can look at to see how it was done?

If you just use VBA maybe you can tell me what you do when you want to write a standalone application. Like an executable file. VB.Net ?

When I raised the question of where to go from Access VB.Net was suggested to me.

[June7]

Still can modify the wizard built forms. Even if you build from scratch, will have to set preferences for form properties (navigation bar, scroll bars, record selector, X close, etc.) and add buttons and other controls. I don't use VBA to build the objects (forms and reports). I use the design tools but I use VBA for the event coding associated with the objects and controls.

VB.net can be used to build interface and connect to various database platforms (Access, SQL, Oracle, etc) but doesn't have its own integrated database storage, which is what Access offers. Access provides interface and data storage functionality. Access can also be used as frontend interface to other database platforms such as SQL and Oracle.

[abrogard]

The way I see it is that Access has the main drawback of being not compiled into a freestanding executable. And associated fact that it needs an Access installation to run on.

I don't like those things just on principle, regardless of how significant they may be in practice. Though when I look around I see many people I might want to provide software to who wouldn't run Access. ( I'm not a pro, just an amateur perhaps returning to the field).

I used to think it had a 'dangerous' user interface, too, but you make me think it is probably capable of being edited so's the user is kept between acceptable constraints.

So that's not a worry, if true.

If there are no other drawbacks I would try to stay with Access as I had some past experience (though I've forgotten so much now) and in particular I feel at home coding the event handlers.

If, perhaps, Access code can be readily converted into a VB.net app somehow or something similar - some way of making it freestanding - that'd be the best of all worlds.

The built in database thing doesn't matter to me much, I think. I am accustomed to having my php stuff accessing SQL databases on my Host computers.

I appreciate your taking the time to discuss this with me. Thank you.

[June7]

It is possible to convert Access file to an executable that does not require an install of the Access app. I just have never done it. For a start review http://forums.aspfree.com/microsoft-...me-206240.html

[abrogard]

Well that's wonderful, or apparently so anyway. I rushed to download it straightaway. The developer extension and the runtime.

Thank you for that clue. Makes it a different ballgame.