Help Newbie

  • Thread starter Thread starter Zoe
  • Start date Start date
Z

Zoe

hello everyone!
I started studying Access two months ago and there's already something I'm
struggling with:
what is the difference (if there's one) between a submask and a secondary
(or sub?) table?

Thanks in advance!
 
Thanks for the answer.
I used the term *submask* because I work with an Italian Progrma and I'm
translating what I see.
Maybe the expression can be *secondary mask*.
What I mean is the a Mask which has an *embodied* mask under it, in which
you write things like (it's my case9 the songs performed at a certain gig
while in the main (above) Mask, as you have things like Name, Venue, Date
you cannot have also the list of songs.
Hope I've been clear.
Click to expand...

I think the English term for this is a "Subform".

Any Form - whether a main form or a subform - is simply a tool to let
you work with data in your Tables. The Tables are the foundation; your
data exists in the Tables, and *ONLY* in the tables.

A Form is just a window through which you can see and work with the
data in the tables.

If you wish to post a description of the specific problem you are
having, we'll try to help!
 
Beppe,
I'll gladly tell you everything I know about Access if you get me
some gigs in Italy :-)
 
Any Form - whether a main form or a subform - is simply a tool to let
you work with data in your Tables. The Tables are the foundation; your
data exists in the Tables, and *ONLY* in the tables.
A Form is just a window through which you can see and work with the
data in the tables.
Click to expand...


Now that was really helpful, thank you!!!
:-)))
I immediately opened an empty Db and tried to build a mask (oops, a form)
:-))) as first thing firts and the message was *you have no tables where
getting data from*
So now I know better.
Thanks again!

If you wish to post a description of the specific problem you are
having, we'll try to help!
Click to expand...


Ok, you're really polite, here!
Now my problem is a pice of cake for you, as far as I understand.
it's a database of gigs (concerts)
In the firts Table (this I have clear) I'd insert Concert ID (key), Name,
Place, Date, Category
In two different Tables, then, I have to insert the songlists for each gigs
and the musicians who played (with a mark I gave just to remember how the
day was) :-)))
But I have problem both in choosing which fields to connect, in choosing the
key and, ABOVE ALL, in how inserting data.
A form in which I have two subforms with the songs to list and another in
which I give marks to each musicians would be perfect.
But I can't build them, I dont' know why.
Should I have a primary key for each song?
Should the second table be just:
SONG ID and nothing more?
And what about the Mark Table?
Hope I've been clear.
Thanks for any help!
 
"> Beppe,
I'll gladly tell you everything I know about Access if you get me
some gigs in Italy :-)
Click to expand...

I read your post more than once but I cant' inderstand if the smile is a
sign of nice feeling or if you're pulling my legs.
In the first case, if you *really* want to play some gigs in Italy, I can
find you tons of dates, not just one
For ex. three in August and three in September off the top of my head.
Just let me know.
Oh, and my *Access problem* is shown in the previous post
:-)))
 
it's a database of gigs (concerts)
In the firts Table (this I have clear) I'd insert Concert ID (key), Name,
Place, Date, Category
In two different Tables, then, I have to insert the songlists for each gigs
and the musicians who played (with a mark I gave just to remember how the
day was) :-)))
Click to expand...

You need a couple more tables. A given song will obviously be played
at more than one concert, and a given concert will have many songs. In
such a many-to-many relationship you need a third table which contains
*the link between songs and concerts*. I suspect you also need links
between concerts and musicians.

I'd suggest at least four tables:

Musicians
MusicianID Autonumber Primary Key
LastName
FirstName
<other bio information>

Concerts
ConcertID Autonumber
ConcertDate Date/Time (don't use Date as a fieldname - reserved)
Venue Text <or have a table of venues>
Category <you may want a little lookup table of categories>
Comments <e.g. "really tough audience here!")

Songs
SongID Autonumber
Title Text
<any other info about the song>

Playlist
ConcertID <where was this played>
MusicianID <who played it>
SongID <what was played>
Comments <about this performance of this song>

In the Playlist table you could select the three ID fields
(ctrl-click) and click the Key icon: a three-field joint Primary Key.
Each ID would be linked to the corresponding table.
But I have problem both in choosing which fields to connect, in choosing the
key and, ABOVE ALL, in how inserting data.
A form in which I have two subforms with the songs to list and another in
which I give marks to each musicians would be perfect.
Click to expand...

Use a Form based on the Concert table, with a Subform based on
Playlist. You could put Combo Boxes on the subform bound to MusicianID
and SongID but displaying the musician's name and the song title.

Hope this helps!
 
Well, it was just sort of wishfull thinking on my part.
I've been doing 'computer stuff' for almost 4 years but for 20
years I made my living playing music. I would tour Germany, Austria
and Switzerland but I never made it to Italy.

Of course I have a day job now that I wouldn't leave (all of a sudden
having a pension has become important) so I'd have to do any playing
on my time off.
Feel free to email if you want to continue this discussion:
(e-mail address removed)

Just remove the NOSPAM.
I could probably get you some gigs over here ( here being Canada)
if you were really interested.
 
Back
Top