Solved Sales Database Relationships (1 Viewer)

iqJafa

New member
Local time
Today, 02:03
Joined
Oct 8, 2021
Messages
20
Hi,
So I'm still trying to get this database working. Can anyone help me with the relationships, what have I done wrong cos when I created a form to record new orders with an invoice subform, there seemed no connection between the tables.
 

Attachments

  • IMG_20211020_164357.jpg
    IMG_20211020_164357.jpg
    3.1 MB · Views: 321

theDBguy

I’m here to help
Staff member
Local time
Yesterday, 16:03
Joined
Oct 29, 2018
Messages
21,454
Hi. For one thing, you are storing redundant information on customer names in multiple tables. It might be better for you to post a copy of your BE with test data.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 00:03
Joined
Feb 19, 2013
Messages
16,610
my guess would be you are using a lookup field for customer in your invoices table.

lookup fields are a bad idea if you want to do anything significant

try linking it to customerID, remove the lookup functionality and rename it as customerID
 

iqJafa

New member
Local time
Today, 02:03
Joined
Oct 8, 2021
Messages
20
Act
my guess would be you are using a lookup field for customer in your invoices table.

lookup fields are a bad idea if you want to do anything significant

try linking it to customerID, remove the lookup functionality and rename it as customerID
I used a combobox where I can choose or enter a new customer on the header of the form. Then I tried to use a list box to be able to select more than one item but it didn't work either.
The subform is to enter the invoice details
 

iqJafa

New member
Local time
Today, 02:03
Joined
Oct 8, 2021
Messages
20
Hi. For one thing, you are storing redundant information on customer names in multiple tables. It might be better for you to post a copy of your BE with test data.
Customer name is actually the customer ID on the platform (Facebook, Instagram, WhatsApp) and the Name is the customer's real
 

plog

Banishment Pending
Local time
Yesterday, 18:03
Joined
May 11, 2011
Messages
11,638
1. Name is a reserved word and should not be used as a field/table name.

2. What does Name hold? You already have CustomerName in tblCustomers, so what's this the name of?

3. Tables with only 1 real field of data (autonumbers don't count) shouldn't exist. Instead of PlatformID in tblCustomers just store the Platform value and not the number reference of it.

4. tblInvlices should hold CustomerID from tblCustomers not CustomerName. Or ditch CustomerID and make CustomerName the primary key. The primary key of one table goes into another to JOIN them, not another field.

5. OrderID should not be in tblInvoices. InvoiceID in tblOrderDetails establishes that relationship, not the other way around

6. CustomerName should not be in tblOrderDetails. Nor should any data from tblCustomers. You obtain that information via tblInvoices which is connected to tblCustomers.
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 19:03
Joined
Feb 19, 2002
Messages
43,233
In addition to the relationship between customers and invoices being inccorect, you are missing at least one table. Putting Platform in the Customer table implies that the customer only subscribes to one of the services you mentioned. I'm guessing that most customers subscribe to more than one service. Therefore, you need a separate table called tblCustomerPlatform. In that table you need intersection data because also, a customer's name may not be the same across all platforms. Therefore, you would put the CustomerName in the junction table that links Cusstomers with Platforms

As the others said, CustomerName does not belong in the details table, nor does it belong in Invoices. Hwever, Invoices needs CustomerID to relate to Customers

Your names are pretty good but you need to avoid reserved words. Two that are especially problematic are Name and Date. There's two ways to do this - either you memorize the names of all reserved words in the Access, VBA, and SQL Server lists or you use combpund names whenever the word is so simple and common that someone has already claimed it. For Name you could use FirstName and LastName since combining all the pieces of a name will cause other problems should you want to send people letters for example. You'd like to say Dear Par rather than Dear Pat Hartman or even worse, Dear Hartman, Pat. Keep in mind that it is always easier to concatenate the parts of a name or address than it is to split them. For the same reason I would split Address into Addr1, Addr2, City, State, Zip. The reason for splitting Address this way is so that you can create a proper label for printing that will pass muster with the postal service. Thinking that you can save time/space/whatever because you will NEVER, EVER have to do anything that requires the individual parts of name and address is shortsighted. Do it now so you never have to face the worse problem of splitting these fields later. If you're in the direct mail business, you go even much further with how you split address because you also need to eliminate duplicates so you separate out cumpass directions, street type designations, house numbers, etc. Plus you standardize them. South is always S and Road is always Rd etc.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 00:03
Joined
Feb 19, 2013
Messages
16,610
I used a combobox where I can choose or enter a new customer on the header of the form.
I was referring to your customername field in the table, not whatever you might have on a form

 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 19:03
Joined
Feb 19, 2002
Messages
43,233
CJ, I think CustomerName is their "face name" or whatever you want to call it for the platform whereas "Name" is their actual name.
 

CJ_London

Super Moderator
Staff member
Local time
Today, 00:03
Joined
Feb 19, 2013
Messages
16,610
@Pat I'm talking about this
1634744669464.png


and questioning whether it is a lookup field
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 19:03
Joined
Feb 19, 2002
Messages
43,233
I know. I said that that field needed to be replaced by the CustomerID. Notice that the existing join is between two non-PK fields so that doesn't indicate a lookup field. CustomerName joining to CustomerID would be indicative of a Lookup field. Also, there must be a unique index defined on CustomerName in order for Access to show the 1-m symbols.

Look at the response in #5 where the CustomerName is explained.
 

iqJafa

New member
Local time
Today, 02:03
Joined
Oct 8, 2021
Messages
20
Hi. For one thing, you are storing redundant information on customer names in multiple tables. It might be better for you to post a copy of your BE with test data.
What does BE stand for?
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 19:03
Joined
Feb 19, 2002
Messages
43,233
BE stands for Back End. All access applications are (or should be) split into two parts. The BE which is Jet/ACE (Access) or some other RDBMS and contains ONLY tables and the FE which is "Access" and contains all objects EXCEPT tables. In the FE (Front End) the tables are linked to the BE. Thy don't actually exist in the same file as the other objects. That allows you to place the BE on a shared drive or use a RDBMS on the server and distribute a separte copy of the FE to each individual user. The users NEVER, EVER share the same copy of the FE. They only share the BE. This minimizes the risk of corruption and allows you to support more concurrent users than a monolithic (all objects together in one big .accdb) would. In fact, if your BE is SQL Server or some other RDBMS, the number of concurrent users is only limited to the number of seat licenses you own for the RDBMS such as SQL Server. So instead of a theoretical max of 255 and a practical limit of ~ 50 concurrent users, you could have thousands. So Access really can support large companies, just not with Jet/ACE as the BE.
 

iqJafa

New member
Local time
Today, 02:03
Joined
Oct 8, 2021
Messages
20
BE stands for Back End. All access applications are (or should be) split into two parts. The BE which is Jet/ACE (Access) or some other RDBMS and contains ONLY tables and the FE which is "Access" and contains all objects EXCEPT tables. In the FE (Front End) the tables are linked to the BE. Thy don't actually exist in the same file as the other objects. That allows you to place the BE on a shared drive or use a RDBMS on the server and distribute a separte copy of the FE to each individual user. The users NEVER, EVER share the same copy of the FE. They only share the BE. This minimizes the risk of corruption and allows you to support more concurrent users than a monolithic (all objects together in one big .accdb) would. In fact, if your BE is SQL Server or some other RDBMS, the number of concurrent users is only limited to the number of seat licenses you own for the RDBMS such as SQL Server. So instead of a theoretical max of 255 and a practical limit of ~ 50 concurrent users, you could have thousands. So Access really can support large companies, just not with Jet/ACE as the BE.
Thank you so much
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 19:03
Joined
Feb 19, 2002
Messages
43,233
You're welcome. Try making the suggested changes and repost the new picture.
 

iqJafa

New member
Local time
Today, 02:03
Joined
Oct 8, 2021
Messages
20
1. Name is a reserved word and should not be used as a field/table name.

2. What does Name hold? You already have CustomerName in tblCustomers, so what's this the name of?

3. Tables with only 1 real field of data (autonumbers don't count) shouldn't exist. Instead of PlatformID in tblCustomers just store the Platform value and not the number reference of it.

4. tblInvlices should hold CustomerID from tblCustomers not CustomerName. Or ditch CustomerID and make CustomerName the primary key. The primary key of one table goes into another to JOIN them, not another field.

5. OrderID should not be in tblInvoices. InvoiceID in tblOrderDetails establishes that relationship, not the other way around

6. CustomerName should not be in tblOrderDetails. Nor should any data from tblCustomers. You obtain that information via tblInvoices which is connected to tblCustomers.
Thank you. It makes more sense to me now (I think). Now I changed both field names and structure and the relationships. Do they look all right now?
 

Attachments

  • IMG_20211020_225811.jpg
    IMG_20211020_225811.jpg
    1.9 MB · Views: 248

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 19:03
Joined
Feb 19, 2002
Messages
43,233
I still think you need five tables. I don't know what your application does but if your users can be on more than one SocialNetwork, this structure won't work. You removed the Platform table but you still have Platform. in the customer table.

Can you confirm that you will NEVER, EVER want to allow a Customer to have more than one Platform association?
 

plog

Banishment Pending
Local time
Yesterday, 18:03
Joined
May 11, 2011
Messages
11,638
Looks really good, 2 questions:

1. What is the Delivery field datatype and what is Delivered field datatype? Are they related in any manner?

2. Is NetAmount calculable from the other fields in tblInvoices? If so, you don't need it. Instead you do the math in a query and then refer to the query when you need that value.
 

Users who are viewing this thread

Top Bottom