form blank in form view

  • Thread starter Thread starter Walter
  • Start date Start date
W

Walter

I saw in a previous post that a form that shows blank in
form view is because it is not setup to allow data entry
and based on a table or query with no records. I am
trying to create a form to use to enter data. I need to
combine the fields from more than 1 table so it needs to
be based on a query, correct? The form I created has all
the data properties (allow additions, deletions, data
entry, etc.) set to yes but when I open it in form view
the only thing visible is the background (all controls
are set to visible). There are no records since I am
trying to make the provision to enter them. How do I
accomplish this?

Thanks,
Walter
 
Walter said:
I saw in a previous post that a form that shows blank in
form view is because it is not setup to allow data entry
and based on a table or query with no records. I am
trying to create a form to use to enter data. I need to
combine the fields from more than 1 table so it needs to
be based on a query, correct? The form I created has all
the data properties (allow additions, deletions, data
entry, etc.) set to yes but when I open it in form view
the only thing visible is the background (all controls
are set to visible). There are no records since I am
trying to make the provision to enter them. How do I
accomplish this?

Thanks,
Walter
Click to expand...


Bear in mind the fact that a query based on more than one table might not be
updateable. Whether it is or not depends on the design of the tables, how
the related keys are indexed and how the tables are joined in the query.
Even with the simplest of examples, say:
tblAlbums: AlbID, AlbName, AlbArtist
tblTracks: TrkID, TrkAlbID, TrkNumber, TrkName
Where AlbID and TrkID are primary keys and TrkAlbID (the related album id in
the tarcks table) is indexed but duplicates allowed.
If I had a form based on a query of these tables, and wanted to allow
additions, what do you think people would expect when they pressed the 'new
record' button? Would they be trying to add a track or an album? What
would the database engine make of the request?
Perhaps you could post some table details?
 
-----Original Message-----




Bear in mind the fact that a query based on more than one table might not be
updateable. Whether it is or not depends on the design of the tables, how
the related keys are indexed and how the tables are joined in the query.
Even with the simplest of examples, say:
tblAlbums: AlbID, AlbName, AlbArtist
tblTracks: TrkID, TrkAlbID, TrkNumber, TrkName
Where AlbID and TrkID are primary keys and TrkAlbID (the related album id in
the tarcks table) is indexed but duplicates allowed.
If I had a form based on a query of these tables, and wanted to allow
additions, what do you think people would expect when they pressed the 'new
record' button? Would they be trying to add a track or an album? What
would the database engine make of the request?
Perhaps you could post some table details?


My goal is to create a database to store mileage, fuel,
Click to expand...
& maintenance records for a small trucking company. In
order to be sure all miles are accounted for, the trip
sheet entry form needs to bring the last trip's ending
location & odometer reading for the specific truck which
can't be changed by the user. For this to work, I need to
be able to establish a beginning mileage and location
when a new truck is added(trucks must be setup prior to
entering trip records). I would like to create a form
which combines the odometer, location, & state from their
respective tables and links this information to the truck
being setup. I probably also need to define this
odometer reading as "Trip End" by default. This form
would open automatically at some point in the setup
process(AfterUpdate property of a control) to be sure
this was done. I have been struggling with trying to
decide how to define the relationships and also if there
could or needed to be more than one relationship on a
table.
Following are tables I have:
.
tblEmployees:
Click to expand...
EmployeeID (autonumber)
Last Name
FirstName
CDLDriver (yes/no)
etc.

tblTrucks:
TruckID (unique # PK)
Make
Year
etc.

tblTripDetails:
TripDetailsID (autonumber)
TripDate
Location (place where trip ends - next trip begins)
TruckID
OdometerID


tblOdometer:
OdometerID (autonumber)
Odometer
O/DDescriptionID


tblOdometerDescription:
O/DDescriptionID (autoNumber)
O/DDescription (state line, fuel, trip end, etc)
OdometerID

tblFuel:
FuelID (autonumber)
Gallons
Cost
OdometerID


tblStates:
State (state abbreviation - PK)
OdometerID


My question is how to relate these tables. I understand
that each truck will have more than 1 trip details. Each
trip details will have more than 1 Odometer reading
(OD). Each trip details can also have more than 1 OD
description, fuel, and state. However, each OD can only
have 1 OD description, 1 fuel, 1 state. Should I relate
OD description, fuel, and state to the trip details table
as a 1:many relationship or should they be related to the
OD table as a 1:1 relationship?

At the end of each calendar quarter, I will have to
generate a report based on the total number of miles
traveled in each state and the total gallons of fuel
purchased in each state for all trucks.
I apologize for the length of this post but I felt you
needed to understand what I was trying to accomplish.
I appreciate you taking the time to look at this.
Thanks,
Walter
 
Walter said:
& maintenance records for a small trucking company. In
order to be sure all miles are accounted for, the trip
sheet entry form needs to bring the last trip's ending
location & odometer reading for the specific truck which
can't be changed by the user. For this to work, I need to
be able to establish a beginning mileage and location
when a new truck is added(trucks must be setup prior to
entering trip records). I would like to create a form
which combines the odometer, location, & state from their
respective tables and links this information to the truck
being setup. I probably also need to define this
odometer reading as "Trip End" by default. This form
would open automatically at some point in the setup
process(AfterUpdate property of a control) to be sure
this was done. I have been struggling with trying to
decide how to define the relationships and also if there
could or needed to be more than one relationship on a
table.
Following are tables I have:
EmployeeID (autonumber)
Last Name
FirstName
CDLDriver (yes/no)
etc.

tblTrucks:
TruckID (unique # PK)
Make
Year
etc.

tblTripDetails:
TripDetailsID (autonumber)
TripDate
Location (place where trip ends - next trip begins)
TruckID
OdometerID


tblOdometer:
OdometerID (autonumber)
Odometer
O/DDescriptionID


tblOdometerDescription:
O/DDescriptionID (autoNumber)
O/DDescription (state line, fuel, trip end, etc)
OdometerID

tblFuel:
FuelID (autonumber)
Gallons
Cost
OdometerID


tblStates:
State (state abbreviation - PK)
OdometerID


My question is how to relate these tables. I understand
that each truck will have more than 1 trip details. Each
trip details will have more than 1 Odometer reading
(OD). Each trip details can also have more than 1 OD
description, fuel, and state. However, each OD can only
have 1 OD description, 1 fuel, 1 state. Should I relate
OD description, fuel, and state to the trip details table
as a 1:many relationship or should they be related to the
OD table as a 1:1 relationship?

At the end of each calendar quarter, I will have to
generate a report based on the total number of miles
traveled in each state and the total gallons of fuel
purchased in each state for all trucks.
I apologize for the length of this post but I felt you
needed to understand what I was trying to accomplish.
I appreciate you taking the time to look at this.
Thanks,
Walter
Click to expand...


Hi Walter
Even though you consider this a lengthy post, there are still a number of
things which are unclear and it's quite a task to decide on a final table
structure - I can often agonise for days over the pros and cons. By all
means re-post the question, perhaps to more than one newsgroup but at the
moment all I can say is that you should bear in mind the overall purpose of
the database - the reporting you mention - and it is that table which should
be the focus of your design.
 
Back
Top