Microsoft Access Beginner
Level 1
Course Handbook Supplement
By Richard Rost
Published by Access Learning Zone
©2021 by Richard Rost and Computer Learning Zone LLC, All Rights
Reserved
Welcome
Welcome to Microsoft Access Beginner Level 1 by Access Learning Zone. I am your instructor, Richard Rost.
This handbook is designed to be a supplement to the full video course; however, it is written so that you should be able to follow along even without the videos. I recommend you use this handbook to follow along with the class videos. I suggest you watch the course videos one time through, paying attention to the lessons covered. Follow along with the course videos using this guide. Take notes on the pages where needed.
Then, watch the videos a second time, practicing the examples yourself in your own database.
Table of Contents
Lesson 00. Introduction (00:00)
Lesson 01. What is Microsoft Access? (14:10)
Lesson 02. Planning Your Database (21:54)
Lesson 03. Getting Started (16:40)
Copyright Notice / Terms of Use
Lesson 00. Introduction (00:00)
learn what Microsoft Access
Lesson 01. What is Microsoft Access? (14:10)
(00:00) In Lesson 1 we're going to learn what Microsoft Access is and what it's used for. You will learn some database terminology. We'll discuss the benefits of a database, and we'll learn about the parts of a Microsoft Access database, including tables, queries, forms, and reports.
(00:23) Before we get started working with Access today let's go over some of the basic database terminology. A computer database is a program that lets you store, organize, and manipulate data. Databases are great for storing large amounts of information. You can use a database to organize that information by generating different reports and queries. You can use a database to manipulate the data and actually make changes to it.
(00:43) In the days before computers, data would be stored on paper, usually in ledger books or on index cards. For example, to keep track of your customers you'd make a series of index cards with one customer per card. You'd have a separate drawer of cards for the products that you sold or the suppliers you did business with. However, as efficient as this may have seemed at the time, it was very time consuming to sort through the cards or to search through a large drawer of cards for some particular bit of information.
(01:16) When the first computers came along, the earliest databases were really nothing more than glorified text documents. They were great for storing information and they certainly made searching and sorting easier, however they lacked many features we take for granted today such as the ability to recognize relationships between the different types of data. For example, you could have a list of customers with some basic details...
(01:40) But if you want to look up information on their purchases you would have to look in a different file. The earliest databases had no way to relate this information together. This creates many problems including having multiple copies of the same information in different places, such as the customer's name and address. Updating all that information can be a nightmare. Fortunately, Microsoft Access does recognize relationships and that's one of its strong points. But much more on that later.
(02:12) The next progression was for people to store their data in spreadsheets like Microsoft Excel. Excel is a great tool for storing small amounts of information and for analyzing data, but when it comes to large amounts of information using Excel can be cumbersome. If you've got more than a few hundred rows of data, you really should be using an Access database. Plus, Excel has the same problem that early databases did: it's not relational. There's no way to link your customers to their orders, or products to their suppliers, and so on. In addition, Excel can be difficult for novice users to work with. If you don't know how to use Excel, finding the information that you want can be daunting. Whereas with Access, you can build a nice user-friendly interface for beginners to easily find their way around. Plus, it's much easier to secure an Access database than an Excel spreadsheet to keep people from messing with data they shouldn't be playing with. With an Access database you can control exactly what people can do in your program.
(03:19) So this brings us, finally, to the modern database. In my opinion, Microsoft Access is the best desktop database application available. An Access database can store large amounts of data much more efficiently than Microsoft Excel or a simple text document. Access databases are also relatively easy to set up compared to other database platforms.
(03:41) An Access database can recognize relationships between your data. For example, if you keep track of customers and their orders you can store all of your customer details in one place and all of their order information in another place. Access can relate those two together, so you don't need lots of redundant information copied throughout your database. You don't need to, for example, copy all the customers information to each order that he places. The database can track that for you automatically.
(04:13) One of the problems with spreadsheets and older database applications is that you have little or no control over what kinds of information get put into your database fields. With Access, you can specify exactly what types of data the user can type into each field. This will prevent for example a number where the customer's last name should be, or a four-digit phone number being entered, or a missing zip code. Access gives you strict controls over the structure of your data and that's a great thing. Yes, it's possible to set up some simple data validation in Excel but Access is much more powerful.
(04:52) Access is a great tool for you to build databases for other people to work with. You can design a very user-friendly interface, so they don't get lost. All of the data entry forms and reports that they need to work with can be presented for them in a nice simple menu, plus since you, the developer, control the interface. You can easily secure your database and lock them out of sections they shouldn't see. Sure there's a little bit of a learning curve to initially get your database set up but once it's built you will definitely save time in the long run and increase productivity.
(05:24) Now Access is a great tool by itself, and I’ve personally built Access databases that have run very small companies with two to five employees and fairly large businesses with hundreds of employees. Access can certainly handle a lot of traffic. However, if you do eventually outgrow your Access database, you don't have to lose all of your work. You can upscale your database to a more powerful backend database server like Microsoft's SQL Server. You simply send all the tables and the data up to the server and you can keep the interface you've built: the forms, reports, queries, and so on. You get the rapid application development of Microsoft Access and the power of SQL Server behind it.
(06:07) Let's talk about the parts of a Microsoft Access database. An Access Database consists of data and the tools to work with that data. What are these tools?
(6:20) An access database consists of tables, queries, forms, reports, and optionally macros, and modules. Tables are used to store data. All of the data in your Access database will be stored in one or more tables. Queries are generally used to organize data. Forms are used to display data on the screen and to edit that data. Reports are for printing out data or formatting information for the printed page. Optionally, for more advanced users, macros are used to automate tasks and modules give you the full Visual Basic programming language inside your access database. Now I have macros and modules grayed out because you can build a fantastic database in Microsoft Access without ever using a macro or writing a line of code. I cover macros and VBA module programming in my Developer level classes, but all you really need are Tables, Queries, Forms, and Reports.
(07:22) All of the data in your Access database is stored in one or more tables. You can think of a table like a single Microsoft Excel spreadsheet. However, tables give you much more control over the types of data that can be input into them. For example, here you see part of a customer table.
(07:41) Tables are made up of a collection of fields. Each field holds a specific type of data. For example, here I have highlighted the last name field in red. This field should only store the customer's last name and nothing else. In fact, you can specify rules in the database to force fields to contain only certain types of information like text, numbers, dates, currency values, and so on. Fields are sometimes referred to as columns just like in an Excel spreadsheet.
(08:16) All of the data concerning one item is stored in a record. Each record consists of the collection of all the fields of data for that item. In this customer table, for example, each record represents one customer. Here I've highlighted one customer, James Kirk, in red. You can think of a record like a row in an Excel spreadsheet.
(08:41) You might not always be storing customers. A product table, for example, holds information on products and each record would represent one product. An order table, for example, holds information on each order that's placed where one record would represent one order. A contact history table, for example, like the one shown here, could store information about each time you talk to your customer. Every phone call, email, etc. will be stored as a separate record. In a timesheet table, for example, each record might represent one instance of an employee clocking in or out. Your tables can store many different types of data: people, places, events, and so on. You should store one type of data per table. Your customer table should hold information on your customers. You wouldn't store product information in your customer table. One of the mistakes that beginners make is they try to store too much information in one table. For example, you wouldn't try to store all of a customer's orders in the customer table. You'd use a second table for that.
(09:48) The data in your tables might not be stored in any particular order. You may have hundreds of thousands of records in your table and the boss says to you. “I want to see a list of only customers from Florida, sorted by last name.” That's what a query is used for.
(10:06) A query can be used to display data in different ways. You can sort your data or apply criteria to only a few specific fields. Queries can be saved and used later so you don't have to keep redesigning them, and someone with little Access knowledge can run your query simply by double clicking on it.
(10:24) Queries can also be used to modify data, add records, delete records, or edit records. We'll learn more about these types of queries, called action queries, in our Expert classes. For today, just keep in mind that queries let you view the data in your tables in different ways.
(10:42) Forms are used for viewing and editing data on your screen. Forms allow you to build a nice user-friendly interface to work with data. Whether you're building a database for just yourself or for other people to work with, forms are a major time saver. You can display information however you want. You can include just the types of data that you want your users to work with. You can combine information from multiple tables such as displaying a summary of a customer's orders on the customer form. You can secure your fields so users can only modify specific fields and can only see other types of data. You may not want all of your employees pulling up credit card numbers, for example. You can also display calculations on your forms such as the total number of days an employee missed work.
(11:33) Your forms can also contain drop-down lists, called combo boxes, so users can select data. Command buttons allow us to perform tasks such as opening other forms or finding records. In fact, you can turn a form into a Main Menu for other forms. The benefits of working with forms go on and on, but essentially, you'll build the interface with which users will work with your data out of forms. You never want your end users to work directly with your tables. You'll build them nice pretty forms they can use to work with the database.
(12:07) Reports are specifically designed to present data to people who are not using your database. You can print a report out. You can send it to someone as an email attachment or as a PDF file. You can use reports to generate all kinds of data customer information, invoices, product catalogs, mailing labels, charts, and lots more. Anything you want to present to someone else can be designed as a report. A lot of times people interchange the words “form” and “report.” in Microsoft Access, they're very specific terms. A form is worked with on the screen whereas a report is generated to be printed out, or at least saved as a printable document. We don't print out forms, and we generally don't work with reports on the screen. You generate them, then you print them out, or you send them to someone.
(13:02) An Access database can optionally contain macros and or modules. These are more advanced topics that I cover in my Developer classes. In a nutshell, macros are generally used to automate repetitive tasks or to carry out simple actions like opening a form. Modules contain the full Visual Basic programming language and can really take your database to a professional level. The good news is you can build a really great database without ever touching a macro or writing a line of code, so if you don't consider yourself a programmer, don't worry about it. You don't have to know these things to build great Access databases. But on the other hand, they are very easy to learn in my Developer classes.
Lesson 02. Planning Your Database (21:54)
(00:00) In Lesson Two we'll discuss planning your database. What tables do you need? What fields should go in each table? What do you want your forms and reports to look like?
(00:10) The first thing you should do when planning a new database is to sit down with paper or a white board and try to figure out exactly what you want your database to do. Plan this out in advance. Make a list of all the features that you want included in your database. What kinds of data do you want to store in the database? What do you want the different forms and reports to look like? What other features do you need? Do you want to store customer information? Name and address, for example? Track correspondence with those customers so every time you talk to them, that's stored in the database? Do you want to generate mailing labels on a regular basis, perhaps to a certain set of customers? Do you want to create quotes and invoices and print those out? Do you want to store order history? Keep track of everything your customers have purchased? Do you want to track employee timesheets, clocking them in, clocking them out, calculating the number of hours they've worked in a week, and so on? Do you want to maintain a product inventory so you know how much of each unit you have on the shelf? Do you want basic accounting features, accounts payable, accounts receivable, all that stuff? These are all things you should write down before you even start building your database in Access. You should know exactly what you want the database to do and have a roadmap.
(01:27) Once you've figured out what you want your database to do, write down the types of tables you think you'll need. Remember all the data in your database will be stored in one or more tables. I like to use index cards one for each table. If you want to use sheets of paper that's fine too. You want all of one kind of information in the same table. For example, all the information about your customers goes in the customer table. All of the information about the orders they place go in an orders table. You wouldn't put order information in the customer table and generally you don't put customer information in the orders table, although there are some exceptions. I'm going to track employees and products in their own separate tables. Employees and products are two completely different things so they each get their own table. Later on, we're going to learn how to relate these tables together. For example, customers can place orders so they can be related to each other but they're completely different things. Customers and employees, although they represent people, and you could certainly store them that way if you wanted to, for the purposes of a beginner database, we'll put them in separate tables. You generally get different kinds of information about employees than you would for customers, so for my beginner lessons I like to separate them. Later on in the more advanced lessons we can put them together because they're both types of people. We'll just have a category on the person table so we can track which ones are employees and which ones are customers. But that's more advanced. We'll get to that later on. Customers can actually place multiple orders so you would not want to store order information in the customer table because you wouldn't know how many orders each customer would place. The customer could have one order, or he could have 500 orders. So that information goes in separate tables. We're going to talk a lot more later on about relating tables together. For now, just remember each type of information goes in its own separate table. People ask me all the time, "well how do I know what tables to make? How do I know which fields go in with tables?" It's literally just a matter of experience. You've got to see some examples to know the right way to do it, and that's what I'm going to show you.
(03:52) Now that you've got an index card for each table that's going in your database, take each index card, for example customers, and write down a list of all the fields or types of data that you want to store in that table. Remember each specific bit of information is considered a field. If we were making an Excel spreadsheet, which more people are familiar with, each field would be a column of data. So, for example, in my customers table I've got basic information like first name, last name, you can put middle name, and all that stuff in there, too, if you want that. I've got address, city, state, postal code, or zip code if you prefer, phone, fax, if you still use fax numbers. I've got a mailing list field which indicates whether or not this customer is on my mailing list. You might have people that you don't want to send your newsletter to, for example.
Customer sense will be a date field, so I know how long this person has been a customer. I've got their credit limit to store a currency value. What's their maximum credit limit? And then finally I've got their email address and some notes. I put a notes field in just about every table.
Now make sure you're as specific as you think you're going to need when setting up your fields. It's easier to put two fields together later, something called concatenation, than it is to try and split them apart, for example. If I just had one field called customer name and later on, I want to send out a mailing that says "dear John," and the customer name field says "John Smith," now I've got to figure out how to split that apart into two fields. So do that up front. It's easier to type in "John" and then in the last name field put in "Smith" then to try and pull that apart later. Address, for example, is another one. Address, city, state, ZIP code, is usually enough for most of my clients. But I have built databases for companies before that do that do heavy mailing lists and they want to split the address field up. You got the number of the building on the street. You've got the street name, like "Main." Then you've got the type: is it a street, drive, avenue, etc. Mailing list companies like to split all that up. Some other companies like address one and address two. Address two could be like a suite number. This is completely up to you. Some companies want a ZIP and a ZIP+4. Again, it's your decision. Decide that now. Be consistent. Just remember if you ever think there's a possibility in the future that you're going to want it separated, separate it now. Be as specific as possible but don't go overboard.
Of course, now one thing you'll notice is that I didn't use any spaces in my field names or my table names. FirstName, for example, is capital F, no space, capital N. MailingList is capital M, capital L, no spaces. In my 20 plus years of building databases I've discovered that it's much, much easier later on if your field names, your table names, and your query names don't have spaces in them. When we start getting into Visual Basic programming and macros and all that stuff, spaces can cause problems. Trust me. Don't use spaces. I will explain a lot more about this in future lessons.
(07:17) One thing I want to address right now at the very beginning of the course is something that people comment about all the time in my Forums, and when they email me. They say that I use the phrase "in a future lesson," or "in future lessons we'll do this," or "I'll teach you about that." It's almost a complaint like people think I'm intentionally withholding information so I could sell more classes. No that's not the case at all. But just like the analogy you have to learn how to walk before you can learn how to run, it's the same with learning how to use computers, or any education for that matter. You can't just jump into calculus without understanding basic arithmetic and algebra. So, when I tell you I'll teach you more about proper naming conventions for tables and for fields in future lessons, we'll cover it when we get to it. I can't teach you everything all at once up front. I wish I could. I wish I could just plug your brain into my computer and download all this information right into your head, but it doesn't work that way. So, when I say we'll cover it in a future lesson, trust me. That usually means I'm going to give you a little bit of information now just to satisfy your curiosity, but we'll go over the details when it's appropriate. If you really want to learn something when I say, "we'll learn about it in a future lesson," I've probably already covered it because I've done this course before in earlier versions of Access. If you really want to learn it, go to my website, search for the topic, and you'll find it. I'm only holding back because I know the proper way to teach this stuff. I've been teaching Access for almost 30 years. So just trust me when I say, "we'll get to it in a future lesson."
(8:56) Now back to designing our tables. Only put customer information in the customer table. You'll notice I don't have any information about this customer's orders in the customer table. I've seen people try to build databases like this where in the customer table they've got order information, order amount 1, order amount 2, order amount 3, and so on. Where does it end? How many order fields are you going to put in the table? Hopefully you're going to want your customer to have hundreds of orders, so it doesn't make sense to store that information in the customer table. Right now, this customer is limited to only three orders and that's bad database design. It's a subject called database normalization which I have whole lessons on. Again, we'll get to that in a future lesson. But for now, just think to yourself customer table, customer information. Order table, order information.
Now I've eased up my stance on this somewhat. The last time that I did this course was back in 2013 and it's now 2021 so I've eased up on this a little bit for only some things. For example, I used to say if you've got multiple phone numbers, multiple email addresses, or multiple physical addresses put them in a separate table. Now, I'll allow you to have max three items because I know a lot of people nowadays have multiple email addresses, multiple physical addresses, or a ship to address, a billing address and so on. So, for beginners, if you want to have two phone number fields or two address fields, that's okay. If it's ever going to be more than three, you're going to put it in a separate table. Again, we'll cover that when we get to making multiple tables. But if you want to have a bill to address and a ship to address in the customer table that's fine. If you want to give the customer the ability to have three email addresses, okay, that's fine. Three is my limit. If you go over that you really should consider making multiple tables for it.
(10:58) Set up a separate order table to put the order information in. Here I've got an order table, an order date, sales rep (that could be an employee), the order total, the sales tax collected, whether it was delivered or not, and so on. All the information about each order will go in the orders table. This, of course, is just a simple example for class, but you get the idea. Later on, I will teach you how to link these two things together with IDs. Each customer will be assigned a CustomerID. Each order will have an OrderID, and we'll link them together using that CustomerID. Each order will have a CustomerID associated with it, so we know which customer placed the order. I will spend lots and lots of time on relationships, a very, very important concept in Access. I devote whole lessons to it, and we will get to that eventually. So, with this setup you can have an unlimited number of customers, within reason. You can have an unlimited number of orders for each customer. You aren't storing order information in the customer table. That's bad. And you generally don't store customer information aside from the ID in the order table, with the exception of maybe a ship to address. You might want to know where the order was shipped, so if the customer moves you can still tell if the order was shipped to his old address. We'll talk about all of that when we get to relationships. Now if this seems at all confusing, don't worry about it. We're actually not going to work with multiple tables and relationships until we get into the Expert series. So, we've got a lot of learning to do first before we get to that point. For now, I just want you to recognize that different types of information in your database will go into their own tables. For today's class we're going to focus solely on the customer table, but later on we'll add other tables like contacts, employees, and eventually orders, products, vendors, and lots more.
(10:59) The next step after you figure out all the tables that you need, is to get out some paper or a whiteboard and draw out the way you want your forms to look on the screen. Remember, forms are what the user interacts with the database with. You do all your data entry and lookups using on-screen forms. And yes, for those of you who are curious, these are the original images I drew for my Access 2010 class over 11 years ago. Way back then I still shipped most of my classes on CD and I kept these images as an homage, and also because I didn't feel like making new ones. No, I'm just kidding. Honestly these images still do the trick. They show you what you need to see. Your sketches don't have to be works of art. They just have to be something simple to guide you as you're building your database.
It's easier to build forms if you have a roadmap, a template that you can see exactly what you want your finished product to look like. Even if you don't know how to do something now, if you don't know how to build what you want in Access, just write down what your brain wants it to look like on paper, and then eventually you'll figure out how to translate that into Access. I'll show you. It's much easier to build a building if you have an architect put together some blueprints. Now, as you can see, I'm no artist, but I do sit down and sketch out what I want each of my forms to look like when the database is finished. Whenever I build a database for a customer, I tell them the same thing: sit down sketch it out on paper. Take a picture of it and send me that so I can see what you want the database to look like - what you want the workflow to be, for example, I've got a main menu on the left with a couple of different buttons on it: customers, orders, employees. I want to click on that first button, the customer button, have it open up the customer form with all the basic customer information on there: name, address, phone number, and so on. I want to see the customer's contact history below that so I can see the last couple of phone calls that we talked about. I want to see the customer's picture over on the right.
Now at this point you might not have any clue how to set this up, but that's what you want to look like for your business, for your workflow. We'll get there as far as translating all that into Access. It's not that tough. Oh, and one tip, actually two tips: tip number one. If you are going to use a whiteboard, make sure you take a picture of it with your cell phone camera and save it. I've had people put stuff on whiteboards that were amazing and then they forgot to save it and then the cleaning staff came in and it was gone the next day. So, trust me, take a picture of your whiteboard. And the second tip is no matter what you see on other websites or when reading books, we do not store files inside our database, like pictures. We don't store attachments. There's something called an attachment field. If you see other things like books or websites talk about these kinds of things, don't do it. Trust me. You'll thank me later. I'll show you how to properly handle this later on. If you're curious and you want to see now, post a comment down below in the comments section and I'll point you to a couple videos I got to cover this kind of stuff. Part of the beauty of having done this course three or four times over the past 20 years is that by now I've got a lot of these videos already made. I don't have to say, "in a future lesson." I can actually tell you, "in Expert 14 we will cover this topic." I'll put helpful links down below the video in the comments section. If you're curious about something right now just click on that link and go right to that lesson. I have thousands of hours of Access training videos on my website. There's very little that I have not covered before. I just redo the beginner lessons every now and then for you new users who have never used Access before. I don't want you to be confused by minor changes in the interface. Access has been very similar since 2007 with some minor differences that I will cover over the course of the next couple hours.
(16:57) The next step is to gather together all of your printed reports, or if you don't have them printed right now, sketch something just like you did with your forms. You've probably got paperwork that you're using right now, things that you're printing out from Microsoft Word or Excel, or forms that have been given to you by an insurance company that you work with, or a vendor, that kind of stuff. Gather all those things together so you can see what kinds of reports you're going to need to build later on. Here, for example, I've got an accounts receivable printout. That's important at the end of each month. I've got an invoice. That's important. I'm going to print that out or email them to my customers. And I've got a set of mailing labels that I need for sending out these invoices.
(17:40) Now an important word about terminology. A lot of people call paperwork "forms." Such as, "here's a form that I want you to fill out for me," and they hand you a clipboard with a piece of paper on it. "Fill out this form." Remember, in database terminology, a form is something we're going to use to work with on the screen, whereas a report is something that is generally designed to be printed out or saved as a PDF file, for example, or emailed. Generally, reports are formatted for print out.
Think forms = screen. Reports = print. You're going to do all of your work on the screen, looking up data, entering invoices, typing in customer data, that kind of stuff, in forms. When you want to print out an invoice, or print out mailing labels, that's going to be reports. Can you go the other way? Can you print out a form? Sure. Can you view a report on the screen? Of course. You can do a print preview and see what it's going to look like. But generally, forms for the screen. Reports for printing, emailing or if you still happen to be living in 1992... Faxing. LOL.
(18:53) So get all your current printed paperwork together. Put it all in a folder. This will make it easy when it comes time to build reports later. You've got all your stuff in one place. You don't have to go hunting around for all the different reports. Speaking as a contract developer, when I used to build databases full-time for other clients, one of the toughest things was that they would say, "I want the database to do this and this and this and this," and I'd build them a database that had maybe 10 forms, some menus, and a few other features. Then they would say "yeah, I need invoicing and I need accounts receivable." So, I put those reports together. Then when the database was all done, they'd be like, "well now I need this report and this report and that report," and give me like 20 different reports that they want to generate. That can sometimes take longer than building the database itself. So definitely take that into consideration when you're building your database, whether it's for you or for your company, or if you're building it for someone as a client. Reports can be time consuming. Trust me.
(19:48) The bottom line here folks is to plan ahead. Don't just get crazy and start jumping into Access and think you're going to build your final company database right now. In fact, one thing I'm going to tell you is while you're learning Access, at least for the next couple of classes, I don't want you to work on your actual company database - your project that you have planned - at all. I want you to build the sample examples that I have for you in class. You will learn better if you follow along with me. Build my database. Don't try to apply it to what you're doing because this is a teaching exercise. I guarantee you between now and the time you finish the class you're going to learn all kinds of new stuff, and you're going to scratch what you've built and start over three times. I've done it myself. A complex database takes a lot of planning, and you don't want to be almost finished with your database then realize, "oh I forgot to put this in." So now you've got to go back and put it in your table, which means you got to update your queries, and add it to all your forms, and add it to the reports. So, try to get this stuff on paper as much as you can up front.
I know it's impossible to think of everything up front. And yes, you can certainly add things on the fly as you're going but the more you plan ahead the more time you will save later. At least figure out all the tables you're going to need, what you want all your forms to look like, all the reports that you need. Don't worry too much about queries. We usually build queries to support a form or to support a report. We'll talk about queries a little bit later. But tables, the fields in each table, the forms, and the reports that you need. Write all that stuff down now before you continue on the next lesson. Once again: plan ahead now to save a lot of time later.
Lesson 03. Getting Started (16:40)
ssss
Copyright Notice / Terms of Use
This course, handbook, videos, and other materials are Copyright © 2021 by Richard Rost and Computer Learning Zone LLC, All Rights Reserved. No portion of these materials may be reproduced, copied, edited, or otherwise distributed without the express written permission of Richard Rost.
Subject to my TERMS OF SALE, Richard Rost grants you a license for ONE PERSON to use this handbook along with the accompanying video tutorials. Your license is non-transferable. You may NOT transfer your license to use (give or sell) the materials to any other party or person. This handbook and accompanying video tutorial are sold on a PER-USER basis. Your copy is for YOU alone. You may not give or sell it to someone else when you're finished with it. I do have volume discounts available for organizations that wish to train multiple people.
This handbook and/or the accompanying video tutorials may NOT be used as part of a training course without express, written permission from Richard Rost and the purchase of an Instructional License.
For details, contact:
Richard Rost
Computer Learning Zone LLC
6900 Daniels Pkwy Suite 29-122
Fort Myers, FL 33912
[email protected]
599cd.com/Contact