dynamic row creation

Look at this:
(not very elegant - but you get the idea...)

kh
 

Attachments

KenHigg said:
Seems you could easily over normalize this db...

???
kh

How can a db be over normalised? in this case if somebody wishes to define/add another type of room then another table and more code to update it has to be created, that's not good design practice
 
Thanx! Ill give it a go and let you know how it works. The idea is to run the append query you created from the VB code for each BRoom that needs creating, right?
 
Yes. Clunky code but you get the idea...

kh
 
Rich said:
How can a db be over normalised? in this case if somebody wishes to define/add another type of room then another table and more code to update it has to be created, that's not good design practice

Hum... Good point.

kh
 
I dont understand the point -- no new tables need creating? All bedrooms are the same. All units have either 0,1,2 bedrooms...
 
Ken

your sample was very helpful -- I am now dynamically creating rows!

It seems that the sub name must be the buttonname_Click(). Is that true?

Also, how many different ways are there to attach code to an event? Before I was writing in a module, but when I went to attach that code to the button click it never appeared in the dropdown box...?

mike
 
In order for this normalization discussion to progress in a rational manner, you would need to divulge all the business requirements you are attempting accommodate with this db. Otherwise it's just an extraneous series yeah/but's...

If it is critical to your business - you may want to do just that...

(all this is just my humble opinon)

kh
 
a little snafu

In order for my form button to work, I have to first click the little > arrow at the bottom of the form that signifies, move to the next record. I think this is because the Unit row does not get created until I click the >, and so clicking the AddRooms button doesnt do anything because the underlying unit is not yet created (Enforced referential integrity).

Suggestions on how to get around this?

mike
 
The on click event for a button is actually contained in the underlying form's class module as is all code associated to the form and is controls.

When you add a button control to a form, (with the tool wizard disabled), you can open the button's properties window and see all the events you can fire off code with. When you select 'on click' in this property window, Access inserts the beginning and ending procedure tags where you put code. If you have other controls and code in the form, you can do pgup/pgdown to see them or you can change an access option that will let you see all of the code at once.

Then you can also do code in custom modules that are independent from form and report objects, that can be called from anywhere in you db...

Hope I haven't made things worse....

kh
 
shrndegruv said:
I dont understand the point -- no new tables need creating? All bedrooms are the same. All units have either 0,1,2 bedrooms...
I'm afraid you're missing the point of normalisation, you only need one table to hold the room details, and a look up table which contains the room description,
Bathroom, Kitchen, EnSuite,Bedroom1,Bedroom2, etc,etc. These are separate records not tables. Just as a curiosity how can you have 0 bedrooms
 
Rich

one of us is not understanding the other.

There are a whole bunch of checkpoints under each of general, kitchen, bathroom, LivingRoom, and Bedroom. In a studio apartment there are no bedrooms (ie seperate rooms for the bed). I could have made one big table, but I decided to divide up each apartment into the sections the building has on its forms. There needs to be a seperate bedroom table in any case, as there are a variable number of bedrooms per unit, unless I wanted every unit to have a bedroom1 and bedroom2 subsection, even if they werent used...
 
Are the flds exactly the same for a bedroom record as they are for say, a kitchen record?

What are the flds (attributes) of each of you room type tables?

kh
 

Users who are viewing this thread

Back
Top Bottom