DataBase

[Udayan]

Anybody help me please.......

I have a switch board or form which shows room numbers permanently shown by
Lable,
Parellel to the room numbers there are:-

List box for regular customer that can be selected using drop down menu only
names
Text box which can enter customer name manually (especially for new customer)

101 ListBoxForRegularCustomer TextBoxForNewCustomer(EnterManualy)
102
103
104
105

The data selecting by listbox and data entering to the text box should go to
a table and save.

How to do this can any body can give a short briefing.
How many tables shall I make what type of query etc.,

I tried so many ways and not succeeding.

I have only two data to manipulate Room numbers and Names.

Thanks in advance

 

[Philip Herlihy]

Anybody help me please.......

I have a switch board or form which shows room numbers permanently shown by
Lable,
Parellel to the room numbers there are:-

List box for regular customer that can be selected using drop down menu only
names
Text box which can enter customer name manually (especially for new customer)

101 ListBoxForRegularCustomer TextBoxForNewCustomer(EnterManualy)
102
103
104
105

The data selecting by listbox and data entering to the text box should go to
a table and save.

How to do this can any body can give a short briefing.
How many tables shall I make what type of query etc.,

I tried so many ways and not succeeding.

I have only two data to manipulate Room numbers and Names.

Thanks in advance

I suspect this may be an academic assignment? Not that that is a huge
issue, but it means the problem is very "bare". You'd normally want to
store more information than a name about either a room or a customer
(especially a customer). What about dates of arrival/departure? If you
post a bit more information you'll get more help.

One difficulty is figuring out how much the solution has to scale. If
this is a meeting room tracking application for a small office, that's
one thing, but if this is central reservations for an international
hotel chain then your users won't thank you for a list box which runs
into thousands of rows (one per customer).

Rule 1: get your tables right first. My solution for this sort of thing
is a three-table approach: Rooms, Customers and Visits, where Visits has
fields for RoomID, CustomerID and dates of arrival and departure. This
is often called an "associative" table.

A combo box combines many features of a List box and a Text box, and can
accept new values (although I'd expect you to have to do more than just
enter a name to register a new hotel guest). In that situation you'd
probably want a form to "Register" a guest, and in the meeting-room
tracker you'd probably want to draw on an existing list of staff?

There's nothing to stop you having two controls "bound" to one field in
the query (usually a query) which drives your form, but I think your
proposed layout is likely to confuse. Better would be to put the text
box on top of the list box (emulating a combo box somewhat) but a combo
box is a more logical choice perhaps.

But does it scale? How many different customers are you likely to want
to handle over the lifetime of the application? Can you fit all those
in a list box? You may want to look at a search facility (with a button
leading to a Register form) instead.

Phil, London

 

[Udayan]

Sir noted,

Actually I have 15 rooms and I was trying to make a data base.
One form showing all the room numbers which is occopied or not.
I dont have any other data only room numbers and guest name may be guest
address also. and whenever I required i need a print out with all the room
numbers and guest name, that's all I needed.

 

[Philip Herlihy]

Sir noted,

Actually I have 15 rooms and I was trying to make a data base.
One form showing all the room numbers which is occopied or not.
I dont have any other data only room numbers and guest name may be guest
address also. and whenever I required i need a print out with all the room
numbers and guest name, that's all I needed.

Well, I've spelt out what the issues are - if you're sure that your
requirements will never evolve, it's ok to simplify things. I'd still
be inclined to have a separate table for Rooms and Persons. You could
include the PersonID in a column in the Rooms table, if all you want is
the current occupancy. Get your table right, then use the various
wizards to build first a query, then a form (for updating) and then a
report. Access does a lot of the work for you - but only if you get
your table design right. Good luck!

Phil

 

[Udayan]

Thanks for your valuable time spared for me.

Well, I've spelt out what the issues are - if you're sure that your
requirements will never evolve, it's ok to simplify things. I'd still
be inclined to have a separate table for Rooms and Persons. You could
include the PersonID in a column in the Rooms table, if all you want is
the current occupancy. Get your table right, then use the various
wizards to build first a query, then a form (for updating) and then a
report. Access does a lot of the work for you - but only if you get
your table design right. Good luck!

Phil

 

[Philip Herlihy]

Thanks for your valuable time spared for me.

You're welcome! Intermediates like me learn a lot from thinking through
the problems in a group like this (but we're not always right when we do
reply). Most people here will have been helped by others at some
critical point, so what comes around goes around.

Best wishes,

Phil