Batch in Access

Batch: A group of statements or database operations processed as an entity. Execution of DOS batch
files, such as AUTOEXEC.BAT, and SQL statements are examples of batch processes.

Batch update: A process in which multiple update operations on a Recordset are conducted on a locally
cached copy of the Recordset. When all updates are completed, calling the UpdateBatch method
attempts to make permanent (persist) all changes to the underlying tables in a single operation. Access
2010’s ADP supports batch updates without the need to write VBA code. See also ADP.

Access 2000 introduced an advanced facility that allows you to create a project file (with an .adp
extension) that contains only your forms, reports, macros, and modules. When you create a new project
file, you can specify an SQL Server database to support the project. SQL Server stores the tables and
queries you use in the application that you design in the project. You can connect your project file to a
database in SQL Server version 7.0 or later, on a server or on your desktop. You can download a special
edition of SQL Server 2008, SQL Server Express Edition, which you can install to run on your desktop
computer from the following location on Microsoft’s website:
http://www.microsoft.com/sqlserver/2008/en/us/express.aspx

An Access Data Project — ADP — is an Access data file that provides access to a SQL Server database.
Using an ADP, you can create a client/server application using Access forms, reports, macros, and
modules, while using SQL Server tables, views, stored procedures, and functions. The .adp file format is
a special database format used by Access to act as a front end to work with SQL Server data. The ADP
user interface looks very much like the standard Access database window you’re already accustomed to.
In fact, creating the user-interface objects is virtually the same as creating them in Access.

An ADP offers three types of queries—views, functions, and stored procedures—and uses the SQL
Server design tools, called the da Vinci toolset for designing queries. (Microsoft used the da Vinci
codename for the toolset during its beta cycle, and it stuck). SQL Server uses Transact-SQL (T-SQL),
another flavor of SQL-92 that has many proprietary extensions to the language. Most of the Access SQL
SELECT query work for creating ADP views.

Access 2010’s Access data projects (ADPs), also called Microsoft Access projects or Access client/server
applications, let you connect to Express and other editions of Microsoft SQL Server 2005 SP2 or later on
your PC; on a peer server running Windows Vista, XP Professional, or 2000 Professional; or on a network
server running Windows 2003 Server or later. Most important characteristics of ADPs are:

1. Like upsized Access applications, ADPs rely on SQL Server tables, but they don’t use .accdb files
to store database front-end forms, reports, and other application objects. ADPs store
application objects in a single .adp or .ade (encrypted) compound document file (DocFile).
2. Unlike upsized Access front-end .accdb files, the .adp file doesn’t contain queries; SQL Server
stores SELECT queries as views. A view is a SQL SELECT query object, which replaces
conventional Access SELECT queries saved as Access QueryDef (query definition) objects.
3. Transact SQL (T-SQL) is SQL Server’s dialect of SQL-92. The current T-SQL version differs
significantly from Access SQL in some areas, but SELECT query syntax is almost identical.
4. SQL Server stored procedures replace Access action queries. Like views, stored procedures are
stored queries, but stored procedures aren’t limited to SELECT queries. Stored procedures are
 especially efficient at processing INSERT, UPDATE, and DELETE operations and managing
Transactions.
5. Project designer windows substitute for Access’s Table and Query Design windows. The da Vinci
query designer’s windows perform functions similar to—but differ in layout from—their Access
counterparts. Table and Query Datasheet views are almost identical to those for Access back
ends.
6. SQL Server offers user-defined functions (UDFs), which you can use to return the equivalent of a
table to an ad-hoc query, view, or stored procedure. User-defined functions support SQL
Server’s linked servers feature to connect to other client/server RDBMSs, Active Directory, and
Index Service. For example, you can connect an ADP to an Oracle database linked to SQL Server.
You also can use UDFs to return scalar (character or numeric) values.
7. SQL Server uses extended properties to support Access’s lookup field and subdatasheet
features, so you don’t lose these capabilities when migrating to the client/server model.
Extended properties also support input masks, captions, and data display formatting. SQL Server
includes system stored procedures to add, read, and remove custom extended properties from
the database.
8. SQL Server has its own panoply of new Extended Markup Language (XML) features, which are
independent of those offered by Access 2010. For example, you can write an XML file that
contains a query and add an XML Stylesheet Language transform (XSL/T) to return data directly
from SQL Server to a fully formatted table in a web page. SQL Server 2005 introduced a new xml
data type, but Access doesn’t support it.
9. SQL Server 2008 offers new geometry and geography spatial data types for location-aware
applications, but Access 2010 doesn’t support them.
10. ADPs dispense with Open Database Connectivity (ODBC) and Data Access Objects (DAO),
substituting OLE DB data providers and ActiveX Data Objects (ADO) for database connectivity
and data manipulation, respectively.
11. You design ADPs in Access’s standard Form and Report views and use the standard Toolbox to
add native Access and ActiveX controls to forms and reports. You can import Access objects—
other than tables and queries—from existing Access databases.

You can use the Upsizing Wizard to convert a conventional Access .accdb application to an Access
project, instead of retaining the Access .accdb front end. ADPs are best suited to the following types of
Access 2010 applications:

1. Front ends to new or existing SQL Server databases. Access 2010 is a very effective rapid
application development (RAD) tool for client/server front ends.
2. New projects that require more robust data storage than an Access database or need the
capability to selectively encrypt individual tables, columns, or even cells with public key
cryptography. Any project that is likely to have more than 25 simultaneously connected users is
a candidate for an SQL Server back end.
3. Applications that you expect to upsize to SQL Server 2008 Express, Standard, or Enterprise
Edition in the near future or even long term. Microsoft has made it easy to migrate ADPs from
SQL Server Express editions on your PC to SQL Server Standard or higher editions running under
Windows 2003 Server or later. Using ADPs, rather than Access tables, ensures a quick and
seamless transition from a local SQL Server Express (SSX) database to SQL Server 2000, 2005, or
2008.
 4. Applications that need to restrict data editing or access to specific tables or queries to specific
users or groups. Access 2010 doesn’t support user-level or group-level security for any objects,
including Access data tables. SQL Server provides very granular permissions to users or groups.
5. Projects that use two-way SQL Server 2005 or later replication to synchronize multiple copies of
the database. SQL Server replication is more robust and flexible than the version offered by
Access 2003 and earlier. (Access 2010 and 2007 don’t support replication).

Applies the result of all modifications made to a batch-type Recordset (LockType property set to
adBatchOptimistic, CursorType property set to adOpenKeyset or adOpenStatic, and CursorLocation
property set to adUseClient) to the underlying table(s) of the data source. The calling syntax is
rstName.UpdateBatch [lngAffectRecords], where lngAffectRecords is a member of AffectEnum (see
Table 32.26).

Creating Batch Updates

ADO allows multiple records to be edited and then committed as a single operation, by calling the
UpdateBatch method. To use this feature, the cursor type must be client-side and the lock type must be
adLockBatchOptimistic.
The Recordset.UpdateBatch Method
The UpdateBatch method writes all pending asynchronous changes in a Recordset to the database when
batch optimistic updating is in use. This method has one parameter.

THE ADO ENUMERATIONS

The ADO object has many different enumerations to represent lots of different parameter options and
property values throughout its object model. The following section describes each of the ADO
enumeration objects discussed previously throughout this appendix. However, this is not a complete list
of ADO enumerations. For a complete listing of all the ADO enumeration objects.

The AffectEnum Members

The AffectEnum is used in conjunction with the AffectRecords parameter of the Recordset.CancelBatch,
Recordset.Delete, and Recordset.UpdateBatch methods.

The CommandTypeEnum Members

The CommandTypeEnum values can be used in the Options parameter of the various Execute, Open,
and Requery methods. For the Execute method, these values can be used in combination with the
ExecuteOptionEnum when specifying values for the Options parameter.
Designing a batch production record database
I'm sailing on a travel that I think I'm not experienced enough to do, so I came here expecting some
guidance because after a lot of research on internet, came with few ideas.

I have been tasked with developing a database to track the production history of different items. The
main problem is, every item is manufactured differently, every one have different ways to be created,
and the parameters that are checked vary a lot from one to another. To rough it up a little more, the
recipe may change over time, so with that can change the parameters that one used to follow, that
means adding new ones or taking out others.

The idea would be to be able to track the batch number, the production order, which item is being
produced and all the variables of the quality control, between other things related to the machinery
used on the process.

At first I thought that I should do a EAV db, but I discarded it, later I found some examples of 6NF that
could apply, but I'm not sure if its fully applicable to the working scheme its implemented here. I would
not like to, but making a table for every single product may end be the only way to work this, but I don't
like that much that Idea either.

Some one of you have worked with something similar to this? If no, still any idea how to give a shape to
this?

Thanks in advance.

I created an application for Clairol that managed the manufacture of various hair care products such as
shampoo and dye. There was a product table, a formula table, and an instructions table. The
components were entered as a percentage so that the batch size was multiplied by the percentage to
get the actual quantity of any particular material in the formula for a batch. Dye packs and colors were
such minute quantities that they were handled separately. The instructions table specified the steps to
take to build the batch and included things such as temperature, mixing speed, and mixing time and
when to reset the scale. Every evening, the application read a production schedule and printed out
batch instructions for the next day for each work station. They were also available on line if the operator
preferred to use the computer to view the instructions. He was required to acknowledge each step.
Some of the machines were automated and the app created files that the machines could read to do
their thing. For simplicity, most materials and formulas were done by weight. Only a few were done
using volume measurements. The instructions table had a FK to the formula table so that the quantities
could be put in the right place in the instructions.

Is that what you are trying to do? Here''s a picture of the printed instructions.
It's mostly something like that, on a related Industry also (pharma). Here they are not giving so much
thought to the ingredients (for now at least, I already see them coming asking for that too!), but for now
they are looking more to each step on the process and all the recorded variables. So eventually, you
could check, how fast was a mill working, or in which room was done certain step to say some examples.

How to Land Your Dream Email Marketing Job: Tips and Tricks

Are you eager to kickstart a career in email marketing but unsure where to begin? Landing your dream
email marketing job can be an exciting and rewarding endeavor. With the right tips and tricks up your
sleeve, you can stand out from the competition and secure the job of your dreams. Here are some
valuable insights to help you navigate the world of email marketing and take your career to new heights.

Everything we made with this application was liquid. I suppose if the end result were pills, the final step
would be extrusion or filling molds. Does this give you a place to start? Also, I edited my first reply to
show a sample.

I think you have sparked something for me with that image you added.

Just to be curious, the "actual" column was to be filled manually (on pen) or it could be completed on
access too? What I'm looking is to track for every batch of the different products those values, but have
in mind that for some processes the recipe part could be half of that while on other processes could be
twice that long.
Why use a database?
If a database is essentially a collection of lists stored in tables and you can build tables in Excel, why do
you need a real database in the first place? While Excel is great at storing and organizing numbers,
Access is far stronger at handling non-numerical data, like names and descriptions. Non-numerical data
plays a significant role in almost any database, and it's important to be able to sort and analyze it.

However, the thing that really sets databases apart from any other way of storing data is connectivity.
We call a database like the ones you’ll work with in Access a relational database. A relational database is
able to understand how lists and the objects within them relate to one another. To explore this idea,
let's go back to the simple database with two lists: names of your friends, and the types of cookies you
know how to make. You decide to create a third list to keep track of the batches of cookies you make
and who they’re for. Because you're only making cookies you know the recipe for and you're only going
to give them to your friends, this new list will get all of its information from the lists you made earlier.

See how the third list uses words that appeared in the first two lists? A database is capable of
understanding that the Dad and Oatmeal cookies in the Batches list are the same things as the Dad and
Oatmeal in the first two lists. This relationship seems obvious, and a person would understand it right
away. However, an Excel workbook wouldn’t.

Excel would treat all of these things as distinct and unrelated pieces of information. In Excel, you'd have
to enter every single piece of information about a person or type of cookie each time you mentioned it
because that database wouldn't be relational like an Access database. Simply put, relational databases
can recognize what a human can: If the same words appear in multiple lists, they refer to the same
thing.
The fact that relational databases can handle information this way allows you to enter, search, and
analyze data in more than one table at a time. All of these things would be difficult to do in Excel, but in
Access even complicated tasks can be simplified and made fairly user friendly.

Taking the Access 2010 tutorial

What to expect from this tutorial

This tutorial will not teach you how to build a database from scratch. It is designed for people who plan
to use a pre-existing database, most likely in the workplace.

The tutorial begins with a basic introduction to Access. You will become familiar with the structure of an
Access database and learn how to navigate various windows and objects contained in it. As the tutorial
goes on, you will learn how to enter information in a variety of ways. You will also learn how to sort,
retrieve, and analyze information by running queries. After you understand how to use your database,
you’ll be introduced to tools that let you modify its structure and appearance.

By the end of this tutorial, you will be able to use a database with confidence. You should also be able to
alter it to best suit your needs.

Batch Processing in Access

I'm working in a small real estate office and have been using Access in conjunction with downloaded
MLS data to help investors find properties with the most equity, with potential for fixing up and selling. I
want to take it to the next level buy being able to do comparables at a subdivision level within the
queries. This would save an immense amount of time looking for candidate properties.

I've got the general idea how to go about it and what needs to be done. For each zip code, there are a
certain number of residential subdivisions. The idea is to standardize the subdivision names in all the
area's zip codes. Once that is done, an average can be taken of the sold properties in each subdivision.
Then, the zip code and the standardized subdivision name can be a combo key to use in a join.

I've been reading a beginner's book on Access VBA, and I've gotten a lot out of it, but it doesn't have any
sections on batch processing and updating of tables. It's mainly about users updating data in tables by
filling out text boxes on a form and clicking a button to update, add, or delete. Can any one direct me to
a good source for batch processing in Access, such as a book or a web site?

I'm not talking about millions of records here, just a few thousand at a time. The data in my tables is
very transient, with records constantly being added and removed as properties come onto the market or
get sold. Thanks in advance.

Use Batch Transactions with SQL Server

to Guarantee Results
Batch transactions are a great way to avoid orphan records and to guarantee the database has
performed all of the actions you have requested. This post will discuss how you can incorporate
batch transactions in Access VBA using SQL Server.
Why Batch?
Normally you would use referential integrity and delete cascade to avoid orphan records, for
example, if you delete a customer record all of the corresponding orders, order details, contacts, etc.
get deleted too. The alternative would be to use batched transactions.

Another common scenario are two or more transactions that must occur together or you end up with
mixed results. For example, if you wish to create an order and order detail records at the same time.
You can’t have order details without a order record, so it’s critical the order record get’s created
before your order details record.

Why would the record not get created, isn’t SQL Server robust?
SQL Server ‘s transaction capability is not the issue here, your program and users are. If you have a
user with a read-write lock on the entire Orders detail table, any new records may not post till that
user’s lock is cleared. Given that the user may have left for lunch and leave the table in that state,
your program may error out before the Reuben on Rye is consumed. There are strategies you
should follow so that your program doesn’t fall to this scenario, but that’s a topic for another, (great),
post.

Consider using Stored Procedures First

There, I said it. Consider using SPs first before using the technique in this article. The advantages
are legion and SQL will always do a better job than Access. Still need to use Access? Then read on.

Recipe Ingredients #1: Mix ADODB connection object with recordset and error handling
To batch your SQL transactions you need to use the BeginTrans , CommitTrans and RollbackTrans
actions of the ADODB connection object. Here’s an example:
Public Function CreateOrder(lngCompanyID as Long)
On Error GoTo ErrorHandler
Dim rs As ADODB.Recordset
Dim strSQL as String
Dim con as ADODB.Connection
Set con = New ADODB.Connection
With con
.ConectionString = "some connection string to SQL Server"
.Open
If .State = adStateClosed Then
'Uh oh, can't connect to SQL
End If
End With
Set rs = New ADODB.Recordset
With rs
.ActiveConnection = con
.Open "tblOrders", con, adOpenDynamic, adOpenOptomistic
con.BeginTrans '<--- FUN STARTS HERE
.AddNew
'Add new record details here
.Update
'Now open a recordset to another table and add new a new record:
.Open "tblOrderDetails", con, , adOpenDynamic, adOpenOptomistic
.AddNew
'Add new record details here too
.Update
End With

ExitProcedure:
con.CommitTrans '<--- If you got this far then commit batch
Set rs = Nothing
Set con = Nothing
ExitFunction
ErrorHandler:
MsgBox Err.Description, vbInformation, "Error:"
Con.RollBackTrans '<---Something wrong? Cancel the whole thing
Resume ExitProcedure
End Function
You will notice that if any error does occur, it will trigger the RollBackTrans method of the connection
object, which would roll back any activity since the batch started, which in this case would be either
the new tblOrders record, tblOrderDetails record or both.

Recipe Ingredients #2: Using DAO Workspace and Execute method.

You may not realize it but DAO also supports transactions just as well as ADO and thus is a good
choice when we’re using only Access data sources. But this time, we’ll execute a SQL statement
instead of opening a recordset:
Public Function CreateOrder(lngCompanyID As Long)
On Error GoTo ErrorHandler
Dim ws As DAO.Workspace
Dim db As DAO.Database

Set ws = DBEngine.Workspaces(0) 'Use default workspace

Set db = ws.Databases(0) 'Use default database
With db
ws.BeginTrans
.Execute "...", dbFailOnError 'Some SQL statements
.Execute "...", dbFailOnError 'More SQL statements
'... do whatever else needs to be done within the transaction.
ws.CommitTrans
End With
ExitProcedure:
Set db = Nothing
Set ws = Nothing
Exit Function
ErrorHandler:
MsgBox Err.Description, vbInformation, "ErrorL"
ws.Rollback
Resume ExitProcedure
End Function
Though both DAO and ADO differs slightly in how you manage transactions, you can certainly
choose to open a recordset or just execute a SQL command with either technology.

Why can’t we do this with bound forms?

Behind the scenes, Access is actually managing the transactions and will be sending transaction
control messages to the backend based on the user’s interactions. At the time of writing, there is no
means to override this behavior. Therefore, if you have a need for batch transaction, it may be
desirable to either consider using an unbound form or a form bound to either a SQL Server View
with an INSTEAD OF trigger or a stored procedure that conforms to updatability rules and binding
the form with an ADO recordset, or a disconnected ADO recordset to simulate batching.

With this in mind, Leigh Purvis, an Access MVP has a testbed sample of using transactions with
forms that may be interesting toward providing additional insights in how Access manages the
transactions behind the curtains. You can find his example at his website and downloading the
“Transaction in Forms” sample.

Happy Batching!

Article written with contributions from Ben Clothier

What's the best method to 'batch process' records from a data entry
session?
I have a system that includes a Purchase form and a Purchase Details subform, one to many relationship
etc. What is the best way to 'hold' the records entered into the subform, before committing them to
disc. The customer needs to be able to check the entered data before it has been saved in the table.

I've thought of make table queries and have been experimenting with recordset clones, but am certainly
not an expert with DAO/ADO programming. However, if i knew the best/preferred method then I would
narrow down how much new I have to learn.

The fields I need to save are called, PurchaseDetails ID, PurchaseID, ProductID, UnitCost and Quantity -
the fields of the PurchaseDetails table. Usually there are not more than 6 rows of such data entered
each time.