Solved

Database Design

Posted on 2011-09-27
49
457 Views
Last Modified: 2013-11-29
Experts,

I am redesigning my db.  
Currently I have a table called tblLetterOfCredit.
Within tblLetterOfCRedit are a few different fields.
The fields are called LocalBankName, IssuingBank, AdvisingBank, ConfirmingBank
The fields all have the same lookup:
   SELECT tblBanks.BankID, tblBanks.BankName FROM tblBanks ORDER BY tblBanks.BankName;

I am thinking that I can replace these 4 fields with one field called [IssuingBank].  

Does this sound like a good idea?  I do not believe I should have the four separate fields with each field describing the type of bank it is.  
0
Comment
Question by:pdvsa
  • 27
  • 17
  • 2
  • +2
49 Comments
 
LVL 92

Expert Comment

by:Patrick Matthews
Comment Utility
Depends.  Is it true that the same bank always plays all four roles for any given LOC?  Or is it possible that different banks will play different roles?

Also, assuming it is possible for different banks to play different roles on any single LOC, would you ever have to run a query like this: "find all LOCs where SomeBank played any kind of role"?
0
 

Author Comment

by:pdvsa
Comment Utility
Maybe I should say that there can be >1 bank to issue the LC (LCID in tblLetterOfCredit).  I think I know what to do but would like to see some comments.
0
 
LVL 92

Assisted Solution

by:Patrick Matthews
Patrick Matthews earned 100 total points
Comment Utility
What you need to do, then, is have a separate, related table for tblLOCBanks.  Your LetterOfCredit table would have a one-to-many relationship to the new table I am suggesting, with the foreign key being whatever the LOC ID is.
0
 
LVL 18

Expert Comment

by:lludden
Comment Utility
You shouldn't have multiple columns linked to the same foreign key table.

If you want to link multiple banks to a record, make a third table

LetterOfCreditID
BankID
BankType

with all three fields as the primary key.  This allows you to add future types without changing your schema.
0
 

Author Comment

by:pdvsa
Comment Utility
Matthewspatrick:
<would you ever have to run a query like this: "find all LOCs where SomeBank played any kind of role"?
yes I would have to do this.  

<Or is it possible that different banks will play different roles?
Not sure exactly what you mean but the same bank will not play >1 role within the same LOC.  
0
 

Author Comment

by:pdvsa
Comment Utility
patrick:  I think you and Lluden are saying the same correct?  
0
 

Author Comment

by:pdvsa
Comment Utility
Should I have the LOC Amount in this new table or keep it in the tblLetterOfCredit?
0
 

Author Comment

by:pdvsa
Comment Utility
it is kind of a big job for me to change this because I have a few reports that will need updating and not certain how the inclusion of this new table wil affect things such as duplicate rows.  
0
 
LVL 18

Expert Comment

by:lludden
Comment Utility
Changing something that is already in place just for the sake of changing it isn't always the best use of time.  When you need to make a change that would break the reports anyway, that would be a more cost effective time to make a schema change.

After taking another look at your tables, it looks like you are only referencing one bank per letter of credit row.  If that is the case, you could move the bank related information to the bank table, but it is not the end of the world to have it where it is now.

Any thing that works is better than a perfect design that doesn't.
0
 
LVL 26

Expert Comment

by:Nick67
Comment Utility
Normalizing data is always worth doing right.
Even fixing it when you've already been gathering data is still worth it.
But is your data normalized?
Have a gander at the attached pdf, and then think about your data.

In my own app, equipment can be owned by one outfit, but another outfit pays the bill.
I have a table tblClients that holds all the information about outfits.
The main table has fields for ConsigneeID and OwnerID, but both of these link to ClientID
In the relationship window, and in query design, I must make tblClients show TWICE, and I draw independent links from each instance to the main table.
That allows the owner and consignee to be different, and yet required and referentially enforced.

independent relations
If each of your four banks (LocalBankName, IssuingBank, AdvisingBank, ConfirmingBank) are independent things and depending on the situation can be four different entities, then your existing structure sounds right.
If in reality a single entity is all four of these thing simulataneously on the same record all the time, then three are redundant.

You have to tell me :)
Normal-Forms-nf3.pdf
0
 
LVL 26

Expert Comment

by:Nick67
Comment Utility
<Maybe I should say that there can be >1 bank to issue the LC (LCID in tblLetterOfCredit).  I think I know what to do but would like to see some comments. >
If that is so, then Patrick is right that issuing bank needs to be in a separate table, since there can be more than one of them for each LOC
What about the other three kinds
<LocalBankName, AdvisingBank, ConfirmingBank> are they singular?
Or can more than one institution fill that role on a single LOC
More than one = separate table
Only one = field
0
 

Author Comment

by:pdvsa
Comment Utility
Ok i have read the responses and i appreciate them.  

Let me pose this scenario.  
If i change the structure and by creating another table as instructed, what happens if i run a report for say LC ISSUED?  

I dont believe i will be able to represent the 4 different bank types per LCID.  
I would want to show the banks involved and all in the same row in tabular format.  

What are your thoughts about this report scenario?

Oh and i do not believe i am truly Normalized.
0
 

Author Comment

by:pdvsa
Comment Utility
PLease see relationship below.  
I created a new table tblBanks_Issuing and it is joined to tblLetterOfCredit on LetterOfCreditID / LCID.

I created a report to better display my dilemma for representing the banks in TABULAR format.
You can see that I can not show ALL of the banks in a single row straight across.
I would want BBVA France and BBVA Argentina to be in the same row with their respective bank type field.

What do you think about this?
 relationship report
0
 

Author Comment

by:pdvsa
Comment Utility
In this screen print, it shows the bank types in tabular format and all in a single row, which is how I want to show the data.  The report is from a previous db.
untitled.JPG
0
 
LVL 26

Expert Comment

by:Nick67
Comment Utility
Worry less about presentation and more about getting the data right, first
Pivot queries and other fun things twist rows to columns when that's needful.

Some of your situation I grasp, other parts I don't.
You've looked through the normalization tutorial.
Your graphic doesn't seem right.
There are many banks
There are many letters of credit
They won't have a direct relationship that way, I don't think.
There will probably need to be an intermediate table

Letter of credit ID =1 was issued jointly by banks BankID 1,3,and 5
the intermediate table would have three records in it
LOC     IssueBankID
1            1
1            2
1            3

But really
<Oh and i do not believe i am truly Normalized. >
That is THE fundamental skill of MS Access.
You have to get your data normalized or all sorts of really difficult problems crop up.

Tables must contain a key, and fields that depend ONLY on that key
A bank--all of its addresses, contacts, whatever
A Line of Credit, its amount, its issue date, its interest rate, its holder whatever

Sometimes you need the intermediate tables (4th and 5th normal forms) and I think you do.
Work it through until you are sure your data is normal

Then it's time for forms and reports, not before
0
 

Author Comment

by:pdvsa
Comment Utility
Nick:

<You've looked through the normalization tutorial.
Your graphic doesn't seem right.
Do you think the relationship between tblLetterofCredit and tblBanks_Issuing isnot correct on LetterofcreditID and  BankenterID?


I also dontcompletely understand how making another table might silve the issue of displaying columns to rows?
0
 

Author Comment

by:pdvsa
Comment Utility
It might be better to see the db instead of going back and forth by text.  
I have paired down the db and there is 1 report that i would like to show that per LetterOfCreditID, all the banks that were involved but in the same row (Tabular) and not in separate rows.  

Can someone help me?  Thank you dearly...
Database1.accdb
0
 

Author Comment

by:pdvsa
Comment Utility
I think i might revert back to the original design.  It seems that normalization can cause issues if you dont know how to do it properly.  Maybe i need a table for each bank type: tblIssuingBank, tblAdvisingBank, tblConfirmingBank. ...to n .  I dont know exactly how reports will show the data if normalization is not done properly.

 
0
 
LVL 26

Expert Comment

by:Nick67
Comment Utility
Don't be intimidated!
<It seems that normalization can cause issues if you dont know how to do it properly>
Normalization doesn't cause the problems, the lack of it does.
And failure to truly see how the data is related.

I am unable at the momemt to look at your sample because it is an accdb and not an mdb.
<Maybe i need a table for each bank type: tblIssuingBank, tblAdvisingBank, tblConfirmingBank>
Or maybe not
@lludden suggestion at ID:36713258 has merit too
Let's say for LineOfCreditID = 1 that 17 banks were involved.
6 were issuing banks, 5 advising, 5 confirming and one local.

You could have a table of BankTypes
BankTypeID     BankTypeDescription
1                     Issuing
2                     Advising
3                     Confirming
4                     Local
(you also have a table of banks already with BankID for each institution)
You could have a table of BanksInvolved
BankInvolvedID    LOCID          BankID          BankTypeID
1                            1                  4                    1
2                            1                  2                    1
3                            1                  3                    1
4                            1                  1                    1
5                            1                  9                    1
6                            1                  6                    1  
7                            1                  7                    2
8                            1                  8                    2  
9                            1                  5                    2  
10                          1                  16                  2  
11                          1                  11                  2
12                          1                  14                  3
13                          1                  13                  3
14                          1                  16                  3
15                          1                  15                  3
16                          1                  10                  3
17                          1                  112                4

This design lets you add as many banks to each LOC as you need, in their various roles.
The idea is that if you need to add more data (in this case BankID's) you should be adding more rows not more columns

The first thing to grasp with your data is "What is the central, unique thing this app is about?"
That seems to be the line of credit.
The next thing is to organize the data so that everything in the table depends ONLY on the primary key
What does that mean?
Well for a LOC, the date it was issued, it's amount, the interest rate, and whom it was issued to are unique and dependent on the LOC only
(probably, I am not a finance guy!)

The BankInvolved table is a join or lookup table.
An LOC has multiple banks involved.
So that table joins the unique LOC to the unique BankID multiple times to reflect that fact.
Each BankInvolved record has the unique values of what LOC and what bank it pertains to, and what role that bank was playing

Data normaliization is tough to visualize sometimes, but its important
<That is THE fundamental skill of MS Access.>
Worry about forms and reports afterward
The horse before the cart and all that jazz.

Get the data model right first.
         
0
 

Author Comment

by:pdvsa
Comment Utility
Nick: I sincerely appreciate your assistance.  Normalization is something I have never dived into.  

I think I have all the requirements you asked in the above as far as the tables:

1. <You could have a table of BankTypes
Well I have a separate table of BankTypes (tblBankType_dropbox)
and within tblBanksIssuing I have BankType with a lookup on that tblBankType_dropbox

2. <you also have a table of banks already with BankID for each institution)
I do have tblBanks

3. <You could have a table of BanksInvolved
I do have tblBanks_Issuing

Regarding the accdb format I have saved it as an .mdb
Maybe when you get a sec you could take a peek at it.
I am thinking that the relationships might be wrong since I have the tables.
What is impt too is that report and how I can make all the Banks on one row.

Thank you sir...
 Database2k3.mdb
0
 
LVL 26

Expert Comment

by:Nick67
Comment Utility
<What is impt too is that report and how I can make all the Banks on one row. >
That is hard to do if the data goes down rows, and not across columns, becaase it goes agianst the grain of the way Access is designed.
But we'll worry about that in a bit.
0
 

Author Comment

by:pdvsa
Comment Utility
I would think that if I had separate tables for each type of bank (like you suggested) then I can have them all in the same row.  OK I will wait...
0
 
LVL 26

Expert Comment

by:Nick67
Comment Utility
I assume there are more tables that you have not included
I see stuff like ProjectID, but that relates to nothing, so I assume you left those tables out.
Those tables that remain look jumbled to me.
Why is EndUserID in tblBanksIssuing?  and ID usually denotes a number.  Why is it text?
I am afraid I cannot understand your data, and that means that I cannot help you.
I am out of my depth.  Intuition and logic only go so far.  I am not a finance guy.

I don't think your data is normalized, but I cannot help you do that beyond what I have offered.
tblEndUser has many fields whose purpose I cannot understand, and so I can't evaluate if they should be there.
tblBanks_Issuing too

I am sorry.  I have no more to offer.
0
 

Author Comment

by:pdvsa
Comment Utility
Nick:
<I see stuff like ProjectID, but that relates to nothing, so I assume you left those tables out.
I did leave it out.  I dont believe it is an important table for this question.

<Why is EndUserID in tblBanksIssuing?  and ID usually denotes a number.  Why is it text?
It is a number on my end.  You might ahve looked at the LCNo field?


What do you think now?
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 

Author Comment

by:pdvsa
Comment Utility
endUserID is in the table because I have a form that will populate who the enduser is.  I wanted to have more information in the table instead of having to develop a query to tell me which Enduser was for that deal.
0
 
LVL 26

Expert Comment

by:Nick67
Comment Utility
<instead of having to develop a query>
That is the entire point of queries, though, to gather the information back together.
And when the data is not normalized then you have to do weird and contorted things to do so

<instead of having to develop a query to tell me which Enduser was for that deal.>
How is EndUser related directly and solely to Bank_Issuing?
Probably not at all
EndUser is related to the deal (LOC?)
0
 
LVL 26

Expert Comment

by:Nick67
Comment Utility
<endUserID is in the table because I have a form that will populate who the enduser is>

That's putting the cart before the horse
You have forms because you have tables you want to put data in.
Not the other way around, not "I have an idea for a form, and now I need a table to store its data"

When you start thinking of form and report design before the data is worked out, the results is tears, wasted effort and frustration
0
 

Author Comment

by:pdvsa
Comment Utility
nick:
<How is EndUser related directly and solely to Bank_Issuing?
<Probably not at all
End User is not related to Bank_Issuing.  
It is just a sort of placeholder for me to open up the table and see the End User per contract

I understand what you are saying.   I was not sure if it was a good idea to do that.  I populate the field with a OpenArgs code.  

EndUser is related to the deal (LOC?)
Yes, because tehre is an End User per LC.  Sorta like the "Owner" of that LC.  
0
 
LVL 26

Expert Comment

by:Nick67
Comment Utility
<I was not sure if it was a good idea to do that. >
Probably not.
<It is just a sort of placeholder for me to open up the table and see the End User per contract>

That's what queries are for.
Queries are virtual tables.
0
 

Author Comment

by:pdvsa
Comment Utility
Got it.  I did not think it could harm anything and now i know it is better not to do that and use queries.

If you have a sec, please try to tell me how to get the banks in the rows instead of the columns.  

I think that i would have to create as many tables as there are bank types?  
0
 
LVL 26

Expert Comment

by:Nick67
Comment Utility
No, I think a structure like in ID:36718691 is maybe better.
A bank is a bank--or not?
Can any bank play any role?

Very quick and dirty, this is how I see the 10,000 m overview of your data

<please try to tell me how to get the banks in the rows instead of the columns. >
Must you absolutely have this?

Look first and see
banks.mdb
0
 

Author Comment

by:pdvsa
Comment Utility
Nick:  
A bank is a bank--or not?
Can any bank play any role?
==>Yes, a bank is a bank and can play any role.

I understand that design banks.mdb  
I can work with that.  

Regarding the report, I do wish to somehow get all the banks in the rows.  Right now, I would not have a LetterOfCreditID, and all the bank players in the same line.  I simply need it that way for ease of printing.  Do I make sense on this report?


0
 
LVL 26

Expert Comment

by:Nick67
Comment Utility
OK,
Look at both reports
<I understand that design banks.mdb >
Is that a correct design for your data?
banks.mdb
0
 
LVL 22

Expert Comment

by:dportas
Comment Utility
To properly implement the business rules you've mentioned and implied by your original design you would also need at least two keys on the participation table, i.e.: (BankID, LOCID) - to ensure that each bank only plays one role per Letter of Credit; (LOCID, BankRoleId) - to ensure each role applies not more than once per L.O.C. Consider adding those uniqueness constraints.

Ensuring that each LOC has banks to fill each role is probably going to be harder - the original design achieves that but any revised design requiring multiple rows per LOC probably won't. In many cases that original design is probably going to be preferable for this reason alone.
0
 

Author Comment

by:pdvsa
Comment Utility
Experts, will get back soon..

Dportas:  i was beginning to think that but i am going to take peek at Nicks db...
0
 

Author Comment

by:pdvsa
Comment Utility
Nick: I think I understand that.  You are using unbound fields and have a rowsource query.  I see that you did not place the unbound field in the Detail Section of the Report.  

My issue is that I dont belive that report will easily export to excel.  
It is because the fields are not all in one row.  

What do you think about having 4 separate tables:  tblAdvisingBank, tblConfirmingBAnk, tblssuingBank, tblLocalBank?  

Maybe this type of structure will be able to show each bank in a single row and all data associated with that LC.  The second row is a different LC with all of its data.
0
 

Author Comment

by:pdvsa
Comment Utility
oh and I like that form.  It has given me some ideas about presentation.
0
 
LVL 26

Expert Comment

by:Nick67
Comment Utility
Oh sure,
Now 38 posts in,
<My issue is that I dont belive that report will easily export to excel.  >
Tsk tsk, now you bring that up :)
That's like after having been instructed on how to drive and fire an M1A1 Abrams tank you say "oh, and could you show me how to fire an AK-47, too?"

I am glad you grasped the listboxes so easily.
Functionally, I don't think separate tables would make much difference.
Think about the listbox rowsource.
What's the differnce between pulling it out of a joint table using 2 parameters and out of separate tables using one?
Nothing really.

I could have achieves the same effect with subforms and no code--but subforms are relatively expensive things to run.
4 of them for such little bits of data may have been borrowing trouble.

Where are we going in regard to your original question?
Will you have more than 4 banks, one in each role, involved in an LOC and therefore need to change your data structure?  Or not?

I have much I can teach you about making Excel howl and wail--but those are separate questions.
And you already have examples of much of what I know about Excel automation :)
0
 

Author Comment

by:pdvsa
Comment Utility
<Think about the listbox rowsource.
<What's the differnce between pulling it out of a joint table using 2 parameters and out of separate <tables using one? Nothing really.

<I could have achieves the same effect with subforms and no code--but subforms are relatively <expensive things to run.

I know you know what you are talking about but to me it seems as though that 4 tables is the solution.    This way you could put the data in the Details section of the report.  Do you know what i mean?  Please fill me in... Thx

0
 
LVL 26

Expert Comment

by:Nick67
Comment Utility
Ok
Here's everything in the detail section on a new report.
The db has a reference to Excel that may break because I am messing with Office 2010 at the moment.
You know how to fix that, right
banks.mdb
0
 
LVL 26

Expert Comment

by:Nick67
Comment Utility
Here it is again, multi-records on each report, everything in the detail section, one line, landscape orientation, Access 2003 compliled
banks.mdb
0
 

Author Comment

by:pdvsa
Comment Utility
Nick:   on the report I see there is some complicated looking code there.  I think I am getting a little over my head.  I have many other reports dealing with banks and I believe I would need to incorporate that code elsewhere and probably on every other report dealing with banks.  

I am siding more with dportas' suggestion that I should stay with my original design.

I believe I could be complicating extraction of data if I dont leave it as a simple design by keeping the LocalBankName, IssuingBank, AdvisingBank, ConfirmingBank fields withi tblLetterOfCredit (as I originally had).  I know this is not a Normalized design but I am not an expert and reverting to Normalization after already designing the db can lead to problems it seems and I would not know how to fix them.

Regarding the Unbound Fields n the report:
I still believe that having 4 separate tables for LocalBankName, IssuingBank, AdvisingBank, ConfirmingBank could be a less complicated way and I would not need a banktype field either as the type of bank would be named within the 4 tables such as fldLocalBankName within tblLocalBank and fldIssuingBank within tblIssuingBank and fldAdvisingBank within tblAdvisingBank.  Or I could just leave "as is" with those 4 fields within tblLetterOfCredit.  I think I would need that code on your report and the unbound fields for all reports basically (which seems quite complicated to me).

What do you think about that last paragraph? I sincerely appreciate your expert insight and spending your time on this.   If you lived in Houston I would buy you dinner and some drinks.




0
 
LVL 26

Expert Comment

by:Nick67
Comment Utility
It comes down to your data.
If each LOC only ever has four banks involved, one in each role, then your original design was fine.
<I know this is not a Normalized design >
If each LOC meets that condition then yes, it is a normalized design.  The issuing bank depends solely on the LOC
If you get more than one bank in each role, then you have problems.
The issuing bank(s) depend on the LOC, but then the second issuing bank depends on the existence of data in the first issuing bank field.
So that is not normalized

The code in the report comes STRICTLY from your desire to have everything on one row.
Access reports really want to put records in columns and fields in rows.
Trying to work counter to that takes effort--hence the code
< I think I would need that code on your report and the unbound fields for all reports basically (which seems quite complicated to me). >

It is the desire to have a single row for data in multiple records that creates the complexity.
Subreports would been less complex, but if your report starts get more than 7 or so subreports on it things tend to get flakey.
Knowing that you have more stuff on the go that I haven't seen, I figured I would demo how to use a listbox to display the data in rows for you.
That way if your final report had subreports, you could use them for things you needed.

I did not comment the code extensively.
Please find the sample attached with more commenting in the code for the report with everything in the detail
banks.mdb
0
 

Author Comment

by:pdvsa
Comment Utility
Nick:
<If each LOC only ever has four banks involved, one in each role, then your original design was fine.
It rarely happens.  I might have alluded to it happening more often.  

I have a final simple question and i will leave you alone.  

If i did have 4 tables as i mentioned above tblLocalBank, tblIssuingBank, tblAdvisingBank, tblConfirmingBank , with a 1:1 relationship to tblLetterOfCredit then is this structure basically the same as having the 4 fields (fldLocalBankName, fldIssuingBank,and fldAdvisingBank, fldConfirmingBank , with a 1:1 relationship to tblLetterOfCredit then is this structure basically the same as having the 4 fields) within the tblLetterofCredit as i have presently?
0
 

Author Comment

by:pdvsa
Comment Utility
Messed up ... Hang on
0
 

Author Comment

by:pdvsa
Comment Utility
Last question was not correct
disregard last paragraph above

here is correct:
If i did have 4 tables as i mentioned above tblLocalBank, tblIssuingBank, tblAdvisingBank, tblConfirmingBank , with a 1:1 relationship to tblLetterOfCredit then is this structure basically the same as having the 4 fields (fldLocalBankName, fldIssuingBank,and fldAdvisingBank, fldConfirmingBank) , within the tblLetterofCredit as i have presently?
0
 
LVL 26

Expert Comment

by:Nick67
Comment Utility
A 1:1 relationship is a rare thing--exactly because it is the same thing as having everything in one table
If you have many, many fields, sometimes a developer will split the tables with a 1:1 relationship as an administrative thing
You'd group the related field together just to make them easier to keep track of.
Access also has a limit of 255 fields per table, and if you had data that would exceed that limit, you'd have to split the table and use a 1:1 relationship
A third reason is indexes.  Access has a limit of 32 per table, so if your main lookup table had 31 or more foreign keys in it, you'd be unable to add any more relationships with referential integrity.  You might split a table into a 1:1 relationship for that reason.
I upgraded the backend of my application to SQL Server for that reason, but a 1:1 split table  could be used for that purpose also

Generally, both tables would then have the same primary key (LOCID probably in this case)

The 1:1  relationship is the rub
<It rarely happens. > is ambiguous.
Either there is NEVER more than 4 banks, or there can be more than 4.
If there's more than 4, then it won't stay 1:1, it'll be one-to-many

Having said that, your understanding is correct
<If i did have 4 tables as i mentioned above tblLocalBank, tblIssuingBank, tblAdvisingBank, tblConfirmingBank , with a 1:1 relationship to tblLetterOfCredit then is this structure basically the same as having the 4 fields (fldLocalBankName, fldIssuingBank,and fldAdvisingBank, fldConfirmingBank) , within the tblLetterofCredit as i have presently? >
0
 

Author Comment

by:pdvsa
Comment Utility
I hope no one has any issue with granting all points to Nick.  

Please let me know.
0
 
LVL 26

Accepted Solution

by:
Nick67 earned 400 total points
Comment Utility
Points should be awarded to those responses that were helpful in answering your question, or state the answer most definitively.
If they happen to be mine, ok
If they happen to be someones else's, ok too
You can summarize a long question like this with a post of your own, and accept it as the answer
You cannot award yourself points, but you then look for the posts that brought you to your answer and award those points

<Does this sound like a good idea?  I do not believe I should have the four separate fields with each field describing the type of bank it is.   >

So, succinctly, my answer was: It depends upon your data.
Much of the rest was helping you to understand how to look at the problem :)
0

Featured Post

What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

Join & Write a Comment

Regardless of which version on MS Access you are using, one of the harder data-entry forms to create is one where most data from previous entries needs to be appended to new records, especially when there are numerous fields and records involved.  W…
QuickBooks® has a great invoice interface that we were happy with for a while but that changed in 2001 through no fault of Intuit®. Our industry's unit names are dictated by RUS: the Rural Utilities Services division of USDA. Contracts contain un…
Familiarize people with the process of utilizing SQL Server functions from within Microsoft Access. Microsoft Access is a very powerful client/server development tool. One of the SQL Server objects that you can interact with from within Microsoft Ac…
In Microsoft Access, learn different ways of passing a string value within a string argument. Also learn what a “Type Mis-match” error is about.

743 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

16 Experts available now in Live!

Get 1:1 Help Now