By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,894 Members | 1,942 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,894 IT Pros & Developers. It's quick & easy.

Access, OleDb, Insert or Update

P: n/a
I'm using OleDb to connect with an Access Database. I have anywhere from
10 to over 100 records that I need to either INSERT if the PK doesn't
exist or UPDATE if the PK does exist, all in a single transaction. Does
anyone have an SQL statement I can throw at it that would accomplish
this?

If I can't figure out how to do it, I'm going to have to send two
discreet SQL commands for each record which will take infinitely longer
than a single transaction.

*** Sent via Developersdex http://www.developersdex.com ***
Dec 24 '07 #1
Share this Question
Share on Google+
13 Replies


P: n/a
Terry Olsen wrote:
I'm using OleDb to connect with an Access Database. I have anywhere from
10 to over 100 records that I need to either INSERT if the PK doesn't
exist or UPDATE if the PK does exist, all in a single transaction. Does
anyone have an SQL statement I can throw at it that would accomplish
this?

If I can't figure out how to do it, I'm going to have to send two
discreet SQL commands for each record which will take infinitely longer
than a single transaction.

*** Sent via Developersdex http://www.developersdex.com ***
With Jet, I don't think you can fire off one statement to do that. I
think you'd need at least two - but there shouldn't be any need to fire
it per each record.

Say table a and b with identical structure, I think you'd first do the
update where the PK exists

UPDATE a INNER JOIN b ON a.id = b.id
SET
a.field1 = b.field1
a.field2 = b.field2
.....

then try the insert

INSERT INTO a
SELECT *
FROM b
WHERE Not Exists (
SELECT id
FROM a
WHERE a.id = b.id)

Technically You're not connecting to an Access database, as such beast
doesn't really exist ;-)

You're connecting to a Jet database, which also happens to be the
default database of Access. But Access can also be used as front end for
other platforms.

I don't know much about the .Net world, but aren't there supposed to be
some automatic update/insert thingies in connection with the data
adapter or datatable (commandbuilder?)? Perhaps an inquiry to a NG
dedicated to the technology you're using might give more precise
answers?

--
Roy-Vidar
Dec 25 '07 #2

P: n/a
Greetings,

.Net is tricking you a little bit. You can combine a
select/Insert/Update/Delete command in a single dataAdapter object. So
you really have 4 separate commands combined into one when you first
create the dataAdapter object. You have to declare each command
individually, then when you fill a dataset with data from a database
table (Access, MS Sql Server, Oracle...) all you have to do is edit your
in memory dataset datatable and the commands you declared will take care
of the rest automatically.

Note: I would steer clear of the command builder object. It creates
generic commands that may not necessarily suit your needs. Here is how
you declare all your command in one shot (at the Form Level):

Imports System.Data
Imports System.Data.OleDB

Dim da As OleDBDataAdapter, conn As OleDBConnection
Dim ds As DataSet

Private Sub Form1_Load(...)...
ds = New DataSet
conn = New OleDBConnection
conn.ConnectionString = "provider=microsoft.jet.oledb.4.0; Data Source =
db2test.mdb"
da = New OleDBDataAdapter
da.SelectCommand = New OleDBCommand
da.SelectCommand.Connection = conn
da.InsertCommand = New OleDBCommand
da.InsertCommand.Connection = conn
da.UpdateCommand = New OleDBCommand
da.UpDateCommand.Connection = conn

da.InsertCommand.CommandText = "Insert Into Table1(FName, LName, Phone)
Select @FName, @LName, @Phone"
da.InsertCommand.Parameters.Add("@Fname", OleDBType.Varchar, 50,
"FName")
da.InsertCommand.Parameters.Add("@LName", OleDBType.Varchar, 50,
"LName")
da.InsertCommand.Parameters.Add("@Phone", OleDBType.Varchar, 50,
"Phone")

'--do the same for the UPdate Command

da.SelectCommand.CommandText = "Select * from Table1"
da.Fill(ds, "tbl1") '--tbl1 gets created automatically inside ds when
calling da.Fill

'--Note: if you are entering/editing data through datagridview control,
then you will have to loop through your dataset table to copy the
entries/edits from the datagridview to the dataset table and then call

da.Update(ds, "tbl1")

the da.Update call will automatically invoke either/and/or the
Insert/Update commands. da.Fill only applies to the Select command.
So, if you are entering data directly into your dataset table from
textboxes, then you don't need to worry about making sure that
entries/edits are already in the dataset table:

Private Sub btnAdd_Click(...)handles btn1.Click
Dim dr As DataRow
dr = ds.Tables("tbl1").NewRow
dr("FName") = txtFName.text
dr("LName") = txtLName.Text
dr("Phone") = txtPhone.Text
ds.Tables("tbl1").Rows.Add(dr)
da.Update(ds, "tbl1")
End Sub

Another Note: .Net may seem a little bit on the busy side or complex -
i.e. for Access. Where ADO.Net is real nice is when you are dealing
with large tables on a sql server DB. Actually, if you have to upload
data from a bunch of Access MDB's to the sql server, ADO.Net is real
nice for that too. It is a straight forward pull and push. You use the
da.Fill command to pull the data from Access to your memory table
da.Fill(ds, "tbl1") and then use the dataTable.CreateReader property of
the memory table to push the data straight to the sql server table. No
data looping involved (I had to write a routine to import data from 50
mdb's in one shot to a sql server db table - it was a snap with
ADO.Net). I did have to set up a loop to import the data from each MDB
to my memory table (all the tables were the same structure for each
mdb). Then I pushed the data in my memory table to the sql server in
one shot:

Dim reader As DataTableReader = dsSql.tblImport.CreateDataReader
dsOle.Tables("tbl1").Load(reader, LoadOption.Upsert)
daSql.Update(dsSql, "tblSql")

Note: have to create the sqlInsert, sqlUpdate commands and all the
parameters for this to work. And if you have at least 2gigs of memory
and at least a 2.8 gig processor, this will upload 500,000 records in a
matter of seconds (the hardware is the catch with .Net).

Rich

*** Sent via Developersdex http://www.developersdex.com ***
Dec 26 '07 #3

P: n/a
Thanks for the help. I'll try the DataAdapter approach. I was just
iterating through the DataTable myself.

Anyway, I'm forced to use an Access file because I was using SQL Express
but I received a "cease & desist" email from corporate. They detected my
SQL instance and told me it was unauthroized and needed to be
uninstalled. So now i'm attempting to salvage our very useful app by
using an MDB file instead.

The file is going to be staged in a shared directory and several people
use the app. So i'm trying to make each connection to the MDB file as
quick as possible to avoid simultaneous hits.

*** Sent via Developersdex http://www.developersdex.com ***
Dec 27 '07 #4

P: n/a
Sorry to hear about the Cease and Desist thing. I have sort of been
there (in a way). If you have to stay with Access, I would use Access
as the front and back end -- unless you just want to stay in practice
with .Net. Otherwise, it might be a little bit overkill. Although, if
you are using VS2005, one nice feature is deploying stuff - you have the
Click Once feature which works nicely with C# 2005 or VB2005 for
deploying your front end and keep an Access backend on the server.

Good Luck!

Rich

*** Sent via Developersdex http://www.developersdex.com ***
Dec 27 '07 #5

P: n/a
Terry Olsen <to******@hotmail.comwrote:
>Anyway, I'm forced to use an Access file because I was using SQL Express
but I received a "cease & desist" email from corporate. They detected my
SQL instance and told me it was unauthroized and needed to be
uninstalled.
Morons.
>The file is going to be staged in a shared directory and several people
use the app. So i'm trying to make each connection to the MDB file as
quick as possible to avoid simultaneous hits.
How many users entering/updating data?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Dec 28 '07 #6

P: n/a
Well, I'll have about 20 people using the app and updating the data. I
don't know too much about Access itself, is it possible for more than
one person to have an MDB file open simultaneously? And not to mention I
expect the database to be about 20MB. Opening that up across the network
in Access would be painfully slow.

*** Sent via Developersdex http://www.developersdex.com ***
Dec 28 '07 #7

P: n/a
There's about 20 people in our work group that will be updating the
data. They are all IT Technicians and the database keeps all the PC
Information (we have around 2000 PC's in our district). The database is
often used because in addition to the PC audit info, it's also used for
our "Netop Phonebook" and disaster recovery information (where is the
current ghost image located for each pc?). It's also used for our
WakeOnLan requirements. So it's a pretty busy database. Shame we had to
lose the SQL db.

*** Sent via Developersdex http://www.developersdex.com ***
Dec 28 '07 #8

P: n/a
Terry Olsen <to******@hotmail.comwrote:
>Well, I'll have about 20 people using the app and updating the data. I
don't know too much about Access itself, is it possible for more than
one person to have an MDB file open simultaneously?
20 users won't be a problem so long as the network hardware and softare is in good
shape.

You want to split the MDB into a Front End MDB containing the queries, forms,
reports, macros and modules with just the tables and relationships in the Back End
MDB. The FE is copied to each network users computer. The FE MDB is linked to the
tables in the back end MDB which resides on a server. You make updates to the FE
MDB and distribute them to the users, likely as an MDE.

See the "Splitting your app into a front end and back end Tips" page at
http://www.granite.ab.ca/access/splitapp/ for more info. See the Auto FE Updater
downloads page http://www.granite.ab.ca/access/autofe.htm to make this relatively
painless.. The utility also supports Terminal Server/Citrix quite nicely.
>?And not to mention I
expect the database to be about 20MB. Opening that up across the network
in Access would be painfully slow.
Um, why would a 20 Mb backend database be slow? Despite urban, ok in this case, IT
folklore, WHICH IS TOTALLY WRONG, Access does not pull down the entire database or
even entire tables unless your selection or sorting criteria isn't indexed. Now in a
WAN situation Access isn't very good. Performance is terrible and chances of
corruption are high. But in a 100 mbps LAN performance is just fine.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Dec 28 '07 #9

P: n/a
Terry Olsen <to******@hotmail.comwrote:
>There's about 20 people in our work group that will be updating the
data. They are all IT Technicians and the database keeps all the PC
Information (we have around 2000 PC's in our district). The database is
often used because in addition to the PC audit info, it's also used for
our "Netop Phonebook" and disaster recovery information (where is the
current ghost image located for each pc?). It's also used for our
WakeOnLan requirements. So it's a pretty busy database. Shame we had to
lose the SQL db.
See my reply to your other posting.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Dec 28 '07 #10

P: n/a
Terry Olsen <to******@hotmail.comwrote in
news:47***********************@news.qwest.net:
There's about 20 people in our work group that will be updating
the data. They are all IT Technicians and the database keeps all
the PC Information (we have around 2000 PC's in our district). The
database is often used because in addition to the PC audit info,
it's also used for our "Netop Phonebook" and disaster recovery
information (where is the current ghost image located for each
pc?). It's also used for our WakeOnLan requirements. So it's a
pretty busy database. Shame we had to lose the SQL db.
With so many functions in one MDB, it sounds to me like you might be
wise to seperate out the different functions into different back
ends, so that should one of them be corrupted, it won't take down
the others.

Of course, that may not be worth the effort if the different
functions are interdependent (and have RI defined between them). But
any complete sets of tables that are related but no related to
others would be a good candidate for pulling out into a different
MDB back end.

Just a thought.

Seems to me that you really ought to go to your direct supervisor
and work up the management chain to get authorization to use SQL
Server.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Dec 28 '07 #11

P: n/a
"Tony Toews [MVP]" <tt****@telusplanet.netwrote in
news:96********************************@4ax.com:
But in a 100 mbps LAN performance is just fine.
It's just fine in 10Mbps, if you know what you're doing. My first 3
professional Access apps (Access 2) were all running on 10BaseT
networks, and they were just fine.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Dec 28 '07 #12

P: n/a
Yup, we're talking about a WAN situation here, a busy WAN and each
protocol is throttled. So it can take a while to open an Access file.

We have a few Access applications that IE put out for the different
locations to use. They have an MDB file in a shared directory somewhere
on the network. We get a lot of calls on those. "I keep trying to open
this file and it freezes up." They wouldn't give it time to open and
were ctr-alt-deleting it. I found it took anywhere from 5-10 minutes to
open.

This I was trying to avoid by writing a FE in VB and using OleDb
Transactions to update the file. But I understand now about breaking it
up into a BE and FE, using Access for both. Now to bone up on my Form &
VBA skills.

*** Sent via Developersdex http://www.developersdex.com ***
Dec 30 '07 #13

P: n/a
Terry Olsen <to******@hotmail.comwrote:
>We have a few Access applications that IE put out for the different
locations to use. They have an MDB file in a shared directory somewhere
on the network. We get a lot of calls on those. "I keep trying to open
this file and it freezes up." They wouldn't give it time to open and
were ctr-alt-deleting it. I found it took anywhere from 5-10 minutes to
open.

This I was trying to avoid by writing a FE in VB and using OleDb
Transactions to update the file. But I understand now about breaking it
up into a BE and FE, using Access for both. Now to bone up on my Form &
VBA skills.
Ah, a WAN is a big problem. Especially a busy WAN. And you've encountered some of
the problems.. You've also been lucky in that the database didn't corruption. Your
best options are Terminal Server or SQL Server.

You might want to go back and try the OleDB etc solutions but I'm not very hopeful.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Dec 31 '07 #14

This discussion thread is closed

Replies have been disabled for this discussion.