need help creating phone charges db

[Abby Lee]

Not sure how to go about this....
We've been entering phone charges in .xls Fields (Number, Lastname First
initial, Group, Voice, Month charges, Detail, Directory, Other, Total,
Reimbursed, month, fund, org, act). I want to create a DB but not really sure
what to do here...took some Access classes some time back.

The following fields need to be added each month (Voice, month charges,
detail, direcory, other, Total, and Reimbursed). All other fields only change
when there is some change such as new person takes over the phone, or a
different account is used for the person's phone charges. However, if a
change is made it cannot effect pryor months records...just future.

Again I don't know how to start this.
Should I have a table just for the name and number with a key...that key
will be used for a monthly charge table and a account information table. Or
should I use a single table?

Are there any samples out there I can use?

 

[John Vinson]

Not sure how to go about this....
We've been entering phone charges in .xls Fields (Number, Lastname First
initial, Group, Voice, Month charges, Detail, Directory, Other, Total,
Reimbursed, month, fund, org, act). I want to create a DB but not really sure
what to do here...took some Access classes some time back.

The following fields need to be added each month (Voice, month charges,
detail, direcory, other, Total, and Reimbursed). All other fields only change
when there is some change such as new person takes over the phone, or a
different account is used for the person's phone charges. However, if a
change is made it cannot effect pryor months records...just future.

Again I don't know how to start this.
Should I have a table just for the name and number with a key...that key
will be used for a monthly charge table and a account information table. Or
should I use a single table?

Well... Excel and Access are VERY DIFFERENT and require different
logic. A "database" in Excel is essentially a flat-file single table;
Access is a relational database. In a relational database you will
need to "normalize" the data into several tables, one table for each
type of "entity" - real-life person event or thing. These tables will
store static, real data; any totals or other calculated fields will
NOT be stored, in *any* table, but will instead be calculated on the
fly.

At a guess (not knowing the exact nature of your needs) you'll need
tables for Customers (number, lastname, firstname, Group, other bio
information); Groups; MonthCharges (with fields for the unique ID of
the person, or perhaps the phone number, depending on whether you
register charges against a number or against a person), and a currency
field for the charge.

You certainly should NOT have a single wide-flat table. How many
tables you have, and how they are related, will depend on your exact
needs.

John W. Vinson[MVP]

 

[Guest]

YOUR TRAINGING NEEDS TO BE UPDATED


CHECK MSDN FOR SQL TRAINGING

 

[John Vinson]

YOUR TRAINGING NEEDS TO BE UPDATED


CHECK MSDN FOR SQL TRAINGING

Your spelling - and your net etiquette - could use a bit of work as
well.

John W. Vinson[MVP]

 

[Chris2]

Your spelling - and your net etiquette - could use a bit of work as
well.

John W. Vinson[MVP]

John,

Please do not feed the *anonymous* Troll.


Sincerely,

Chris O.

 

[John Vinson]

John,

Please do not feed the *anonymous* Troll.

Good point. We should have a stock of Troll-House Cookies to offer
instead...

John W. Vinson[MVP]