Access 2007-2019
Access 2000-2003
Access Seminars
 		TechHelp Support
Tips & Tricks
Access Forum
 		Course Index
Topic Glossary
Insider Circle
 
Home   News   Tips   Glossary   Templates   Forums   Help   Logon   Order   Contact Us  
 

News      User Comments     History     Notify Me

5/4/2014 3:24:36 PM
Microsoft Access Expert 20
By Richard Rost   Richard Rost on Facebook Richard Rost on Twitter Richard Rost on Google Plus Richard Rost on LinkedIn Email Richard Rost

 
 Microsoft Access Expert Level 20 is 1 hour, 49 minutes long. In this class we will focus on importing and linking to external data sources, and sending mass email. Topics include:

- Sending Mass Email from Access
- Importing Data from Microsoft Excel
- Linking Live to Excel Spreadsheet Data
- Importing Text Files
- Importing Data from HTML Pages
- Importing and Exporting XML Data
- Saving XML Schema Data (Table Info)
- Linking to Outlook Folders
- Reading & Editing Inbox & Contacts

Click here for more information on Access Expert Level 20, including a course outline, sample videos, and more. This course was recorded using Access 2013, but is also valid for Access 2007 and 2010 users. This class follows Expert Level 19. The next class in the series is Expert Level 21.

Permanent Link
Course Link: Microsoft Access Expert 20
Keywords: access expert 20 importing linking excel html xml xsd outlook contacts inbox
Page Tag: whatsnew
Post Reply

Is it possible to import Excel file to Access tabl Comment from Thomas Szypulinski @ 12/7/2015
Is it possible to import Excel file to Access table when it is not set as table, but it is more like a document where data is located all over the sheet.
please see below.


SET-UP INFORMATION      
      
PART NO:  JRB7178  MACHINE PROGRAM #:  T06-01-0025
CUSTOMER:  ROLLS ROYCE  REVISION / UPLOAD DATE:  12/7/2015
CYCLE TIME:  ?  OPERATION SEQ. NO.:  164
    PROGRAM ORIGIN:  "z" zero is front face of part
KIT NUMBER:      
      
WORK HOLDING:  SOFT JAWS  CHUCK PRESSURE:  
GRIP LENGTH:  0.0267  TAILSTOCK PRESSURE:  n/a
SPACER LENGTH OR T#:  n/a  SPACER LENGTH OR T#  n/a
      
      
Restart #               TOOL NO.: Offset# OPERATION: Tool Description Capto Insert Length
      
N007 1 1 ROUGH FACE C4-DCLNR-27050-16 Y CNMG-432
      
N181 5 5 ROUGH BORE R571.35C-403227-15 Y DNMG-432
      
N016 2 2 FINISH FACE C4-DCLNR-27050-16 Y CNMG-432
      
N025 7 7 FINISH BORE R571.35C-403227-15 Y DNMG-432
      
N074 11 11 FINISH WEB C4-TLSL-27050-3 Y TLR-3094R
      
N105 9 9 GROOVE C4-TLSR-27050.3 Y TLG-3142L

Reply from Alex Hedley:

I've done something similar with REGEX with a HTA. Take a look at the link and let me know how you get on
Show Just This Thread        Post Reply
Email Recipient Comment from vicki Hudson @ 5/3/2015
Maybe a dumb question but, Where does it tell the email recipient who the email is from? Can I use something other than Outlook?

Reply from Alex Hedley:

I'm not sure I understand the question?
You pass in the From address when you send the email programatically.
You can use SMTP from Gmail/Yahoo etc as shown in the Email Seminar.
Show Just This Thread        Post Reply
Import Excel into Access Comment from vicki Hudson @ 3/13/2015
I have an xcel spreadsheet that calculates ride times for multiple riders and multiple loops on separate sheets for multiple mileage,  and results with Multiple column headings. Those are calculated and sorted on a separate sheet.  Does importing it bring over the formulas in the fields for each sheet?

Reply from Alex Hedley:

No it will just bring in the values.
You could create Caclulated Fields
Show Just This Thread        Post Reply
Mail Merge Comment from Nicholas S @ 3/4/2015
Hi does anybody know why I am getting this meesage please?

thanks

Nick

Reply from Alex Hedley:

Which version of Word are you using?
https://support.microsoft.com/kb/318532


From an MS Forum:
ODBC operates at a low level, it doesn't "know" about Access forms.
You can use DDE instead of ODBC to connect to the database, although it's somewhat flaky:

In Word 2007, click the Office Button, and then click Word Options.
On the Advanced tab, go to the General section.
Click to select the Confirm file format conversion on open check box, and then click OK.
When you select the Access database as data source for your mail merge, the Confirm Data Source dialog box will be displayed.
Select MS Access Databases via DDE (*.mdb, *.mde), then click OK.
Proceed as usual.
Or find a way to do without the parameter.

From SO
The path to you ODBC database is configured in your ODBC settings. Where this is updated for Office 2007 depends if you have a 32 or 64 bit OS.

If you have a 32-bit OS use the Database Sources (ODBC) under Administrative Tools

If you have a 64-bit OS use Database sources (ODBC) from c:\windows\SysWOW64\odbcad32.exe

Office 2007 is a 32 bit application and can only read 32-bit ODBC data souces. Using the settings under Administrative tools on a 64-bit machine sets ODBC for 64-bit applications. Confusing I know.

Here's one reference on this http://support.microsoft.com/kb/942976
Show Just This Thread        Post Reply
Mail Merge Comment from Nicholas S @ 2/23/2015
Hi, I fell at the first fence, when I click Mail Merge I get this message.

ODBC Microsoft Access Drive Login Failed

Could not find file 'C:\Users\owner\Desktop.mdb'

To be honest I am not suprised it cant find it, it doesnt exist.

Does anyone know how I can ovecome this

Very many thanks

Nicholas

Reply from Alex Hedley:

It's been a while since I've used the mail merge, I thought you chose the data source in one of the steps.
Let me look into and get back to you.
Maybe another student has had the same error and can assist.
Show Just This Thread        Post Reply
Importing Duplicates Comment from Michael A @ 8/13/2014
Hi,

Yes, thanks. I realised this and figured I should really go back and delete the question.

Thanks, Mike
Show Just This Thread        Post Reply
Importing Duplicates Comment from Michael Adams @ 8/9/2014
Hi,

I have a situation where I have to important customer information from multiple ticketing agencies for the theatre company I work for and I have a couple of questions about importing that I hope you can answer for me.

Firstly, I get a report from an agency which includes their UID for the customer. That is different to the UID I have for the customer. I don't want to overwrite that customer data every time I do an import and I don't want to append the data or I will end up with duplicate records for each customer. Is there a way I can upload only new records?

1. Would this be by making the attribute with the agency's UID in it indexed and not allowing duplicates?

2. would this be best managed by having an import table which is rewritten every time and then a series of queries that contain a criteria that excludes records if the AgencyUID in my main customer table does not equal the UID of the imported data, and  then appends the result of that to my main customer table?

Second issue, as I mentioned earlier my theatre company deals with multiple ticketing agencies because we do a lot of touring. This means at the end of the year I could end up with 8 John Smiths being imported if John Smith had attended a show in each of the 8 different venues. This is annoying. I would like to have a single view of the customer so that I can create queries and reports that show that customer's overall purchasing behaviour. How would you solve this situation? Would you have each agencyUID in the main customer table? Would you have a many to many table situation set up? Then on the importing data front, I think the issue is the same the one above, how would i not create multiple records for the same customer? Would the process of relating an existing customer to a new agency UID need to be a manual process the first time that agency UID is uploaded?

Thanks, Mike

Reply from Richard Rost:

Michael, your first question will be answered in Expert 22 where I cover importing price changes from vendors. You would basically keep the vendor's ProductID in your database in addition to your own. This way your database knows which products already exist - and just to update the pricing, rather than import the entire record.

You would need some sort of unique way to identify each John Smith - a phone number or email address, perhaps. Once you have that, you could certainly set up a unique record for him in a customer table, and then many-to-many relate him to an agency table.
Show Just This Thread        Post Reply
Microsoft Access Expert 20 Comment from AccessJunkie @ 5/8/2014
Now I'm hooked.....I need to try the Email seminar when I get back from SoCal.
Show Just This Thread        Post Reply
I might have posted this in the wrong spot earlier Comment from Bryan Wells @ 5/7/2014
I might have posted this in the wrong spot earlier (comment approved but don't see it) so posting again-apologies if a repost:

Hi Richard, great lesson!  I'd really appreciate some discussion on "when normalization and imports collide".
Let's take the following example (related to class materials).  I already have Anna Picore in my database as a customer.  I have a sales department and am relying on their users to populate excel import templates for customer comments.  Now we have a conflict-the sales team doesn't think of Anna Picore as Autonumber 12.  Also, say in addition to adding the comment, I have a "comment type" and following good database normalization methodology, I don't simply have "inquiry, comment, feedback", I have commenttypeid 1, 2, and 3.  Well now that sales rep has to populate an import template with customerID=12, commentID=2, Comment=Rick is a swell guy.    
Any thoughts from a broad strategic level on the clash between good normalization and not driving coworks crazy with "weird" import templates?  Are there some tips/tricks to keep good normalization while making the population of import templates more friendly to the "non-db expert" eye?  
My end users want to think of users as people, comment types as actual comment types, account types as actual account types etc without having to look up what the corresponding autonumber is.

Really appreciate both Richard's and the rest of the class's thoughts on this!
B

Reply from Richard Rost:

Well, if you have other people entering data about your customers into a spreadsheet, and you want to be able to EASILY import that data later, you need SOME kind of key field. You can make up your own secondary key if you want... perhaps call Anna Picore "APICORE" or whatever, but if they just go by her name, then you run into problems if you someday get a 2nd Anna Picore in your database.

Instead of having your users put data into Excel sheets, the BETTER solution is to make them a remote data-entry database, like I'm going to show in either X21 or X22.
Show Just This Thread        Post Reply
Comment from b @ 5/5/2014
Hi Richard, great lesson!  I'd really appreciate some discussion on "when normalization and imports collide".
Let's take the following example (related to class materials).  I already have Anna Picore in my database as a customer.  I have a sales department and am relying on their users to populate excel import templates for customer comments.  Now we have a conflict-the sales team doesn't think of Anna Picore as Autonumber 12.  Also, say in addition to adding the comment, I have a "comment type" and following good database normalization methodology, I don't simply have "inquiry, comment, feedback", I have commenttypeid 1, 2, and 3.  Well now that sales rep has to populate an import template with customerID=12, commentID=2, Comment=Rick is a swell guy.    
Any thoughts from a broad strategic level on the clash between good normalization and not driving coworks crazy with "weird" import templates?  Are there some tips/tricks to keep good normalization while making the population of import templates more friendly to the "non-db expert" eye?  
My end users want to think of users as people, comment types as actual comment types, account types as actual account types etc without having to look up what the corresponding autonumber is.

Really appreciate both Richard's and the rest of the class's thoughts on this!
B
Show Just This Thread        Post Reply
Comment from Roger Owens @ 5/5/2014
I have been writing access 2000 programs since it came out.  Right before that I started with access 97.  In just the last couple of months I purchased access 2013 because I discovered that my access 2000 database programs would not run on Win 8.

I learned access on the fly and there weren't any tutorials available.  I'm sure I missed things.  So now I'd like to start at the beginning in access 2013 learning everything about it.  I just finished levels 1 & 2.  Do you have an access 2013 level 3?
Show Just This Thread        Post Reply

Add Your Comments or Subscribe
 
If you just want to subscribe to get email updates when the News is updated, then enter your name and email address and check the Notify Me box below. If you would optionally like to add your comments below to be posted, they are welcome.
 
  Your Name:  Required
  Your Email:  NOT Public
  Subject:
  Comments:

 

Sorry about this step. It's just to keep the spam bots away:
  Verify: What is 8+2:
  
  Notify me when the News is updated.
  Remember Me for my next comments
  
 
 
Please do not use this form for Customer Service inquiries! If you have questions about your account, shipping info, courses you've ordered, need passwords, etc. please use the Customer Service Center instead.

I value your comments. They will be displayed on this page (above). Your name will be displayed, but your email address will not be. As always, I promise to never give away your personal information to anyone else, ever.

NOTE: If you don't leave your name and email address, DON'T expect a reply. I can't promise a personal reply to everyone who posts here. I TRY my best, but I cannot guarantee it. If you don't leave your real name and email address, I won't even bother. I usually just hit DELETE. -Richard

 

 

You may want to read these articles from the 599CD News:

8/15/2019Last Chance for Access CDs
8/1/2019Customer List Form Template
8/1/2019New Template Access Customer Database
7/30/2019Microsoft Access Developer 13
6/20/2019TIP: Validation Rules in Access
11/20/2018Microsoft Access Developer 12
8/25/2018NEW: Access Dev 9, 10, 11
8/25/2018Microsoft Access Developer 11
8/25/2018Microsoft Access Developer 10
8/25/2018Microsoft Access Developer 9
 

Learn
 
Accessindex
Excelindex
Wordindex
Windowsindex
PowerPointindex
Photoshopindex
Visual Basicindex
ASPindex
Seminars
More...
Customers
 
 Account Login
Online Theater
Downloads
Lost Password
Free Upgrades
Insider Circle
Student Databases
Change Email
 Info
 
 Latest News
New Releases
User Forums
Topic Glossary
Tips & Tricks
Articles
Search Our Site
Waiting List
Production Schedule
Collapse Menus
 Help
 
 Live Chat
Customer Support
WalkThru Tutorials
Troubleshooting
FAQs
TechHelp
Consulting Services
 About Us
 
 Background
Testimonials
Jobs
Affiliate Program
Richard Rost
Free Lessons
Mailing List
 Order
 
 Video Tutorials
Handbooks
MYOLP Memberships
Idiot's Guide to Excel
Volume Discounts
Payment Info
Shipping
Terms of Sale
Gift CDs
 Contact
 
 Live Chat
General Info
Support Policy
Contact Form
Email Us
Mailing Address
Phone Number
Fax Number
Course Survey
 Facebook    Twitter

Google Plus    LinkedIn

Blog RSS Feed    YouTube Channel 		Richard Rost Microsoft MVP