Automating Access to SQL Server

We're trying to put a view of data maintained in desktop Access databases online and into SQL Server.
The desktop Access system uses separate databases instead of tables within one database, It's a strange design, but it can't be changed.
We have been importing all of the separate databases into a single, new Access database, then upsizing the new databse to SQL Server, then uploading it.
This is not going to work long term, because we are stuck with a 250 mB Access database to upsize and upload, when we never need to update more than 2 or 3 of the tables and upload more than 2 mB.
We'd like to be able to upload only the tables -- preferably the Access *.mdb's -- that have changed, and then replace the SQL Server tables with the new information. And we'd like to automate it as much as possible, without upsizing Wizardy.
I don't know where to even begin looking for information about how this might be done.
Any suggestions would be deeply appreciated.
- Tinker
This sounds possibly like a job for DTS. You could set up a DTSpackage on the SQL Server that will loop through the Access databasesand perform the updates as needed.
This site is a good resources for DTS work:http://www.sqldts.com.
|||Hi Terri, and thank you.
When I first ran across information about DTS, I skipped right past it. I'm curently out in the MS Tech Net learning more and it appears DTS may be much closer to what we want to do than I first thought.
Neither the FAQs athttp://www.sqldts.com/ nor the information I have trolled-through so far on the Tech Net discuss automating DTS; is that possible?
While we don't want to ride herd on these data updates any more than is absolutely necessary, it would be super great if I don't have to try to program my way through deleting all the records in an SQL table, then refilling the table with the new records...
Appreciate your suggestion,
- Tinker|||Sure, it's possible to automate DTS. You can use SQL Agent toschedule a DTS package to run on a schedule of your choosing.|||Thank you. I finally found where I get to do all this.
Sometimes I feel dumber than usual... 8-)
- Tinker

Automatically run a stored procedure at 6am every day?

Hi All,

I'm wondering if anyone can point me at some online resources that
demonstrate how to run a stored procedure against an SQL Server 2000
server at 6am each day?
Any help much appreciated!

Much warmth,

planetthoughtfulhttp://msdn.microsoft.com/library/e...tomate_4v1v.asp

--
David Portas
SQL Server MVP
--|||http://msdn.microsoft.com/library/d...p_adda_9tbk.asp

auto-commit vs begin transaction overhead

I've googled for the answer and searched sql server 2005 books online and I haven't been able to find the answer to my question. My main question is what is the difference in overhead between using auto-commit on every statement or explicitly calling begin transaction on every statement. I'm basically looking for documentation that points to the difference. Read on for the scenario...

We have an application that has problems with deadlocks. Part of our strategy in handling these deadlocks is resubmitting the transaction. My solution to this part of the strategy is to wrap every storedprocedure in a transaction so this would include reads and writes. My architect has raised some concerns with regard to performance if it's implemented this way. I've come across documentation (http://msdn2.microsoft.com/en-us/library/ms187878.aspx) in the sql server 2005 books online that auto-commit happens on every statement anyway but haven't come across anything that explicitly states the performance penalty if there is one. Is there difference in overhead between calling 'BeginTransaction' for every statement or just letting auto-commit do it's magic. Is this implemented in SqlClient object or at a database level?Some folks from the database engine team would be best suited to answer your question re: auto-commit vs. explicit transaction performance. Depending on their answer, you might also want to follow up with folks in the .Net Data Access and Storage forum to ensure there are no performance implications in the particular client that you are using.|||

AFAIK, definetely there is an overhead. And how much overhead depends on the traffic on your application, and the size of the DB.

There will be lot of contention since transactions will keep the locks until the transaction commits. You might see slow down in your transaction times. If you have a web form and a submit button, you keep the user waiting longer for his transaction to commit if there are more transactions waiting. Also, there could be timeout issues. Your CPU could shoot up. If you use #temp tables your tempDB could blow up.

If you have dead lock scenarios I would look into which procs cause it and fix them rather than wrap every T-SQL with a transaction.

And if you really want to measure the overhead, you can use some 3rd party tools like NetIQ and do a load test and quantify the results.

Auto Stats

Books Online does not explain how this runs for SQL Server 2000 (we are on
SP3a).
Does it take any database or other locks at all ? So that it could
contribute to a timeout/disconnect problem we are getting ?
I don't believe so. I think it's unlikely that that is contributing to
any timeout problem, but you can always disable that option (ALTER
DATABASE <dbname> SET AUTO_UPDATE_STATISTICS OFF) and see if the timeout
problem goes away (just do the statistics updates manually (EXEC
sp_updatestats) out of hours).
*mike hodgson*
blog: http://sqlnerd.blogspot.com
Jim Trowbridge wrote:

>Books Online does not explain how this runs for SQL Server 2000 (we are on
>SP3a).
>Does it take any database or other locks at all ? So that it could
>contribute to a timeout/disconnect problem we are getting ?
>
>

Auto Stats

Books Online does not explain how this runs for SQL Server 2000 (we are on
SP3a).
Does it take any database or other locks at all ? So that it could
contribute to a timeout/disconnect problem we are getting ?This is a multi-part message in MIME format.
--010006090901020804020402
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
I don't believe so. I think it's unlikely that that is contributing to
any timeout problem, but you can always disable that option (ALTER
DATABASE <dbname> SET AUTO_UPDATE_STATISTICS OFF) and see if the timeout
problem goes away (just do the statistics updates manually (EXEC
sp_updatestats) out of hours).
--
*mike hodgson*
blog: http://sqlnerd.blogspot.com
Jim Trowbridge wrote:
>Books Online does not explain how this runs for SQL Server 2000 (we are on
>SP3a).
>Does it take any database or other locks at all ? So that it could
>contribute to a timeout/disconnect problem we are getting ?
>
>
--010006090901020804020402
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>I don't believe so. I think it's unlikely that that is
contributing to any timeout problem, but you can always disable that
option (ALTER DATABASE <dbname> SET AUTO_UPDATE_STATISTICS OFF</tt><tt>)
and see if the timeout problem goes away (just do the statistics
updates manually (EXEC sp_updatestats) out of hours).</tt><br>
<div class="moz-signature">
<title></title>
<meta http-equiv="Content-Type" content="text/html; ">
<p><span lang="en-au"><font face="Tahoma" size="2">--<br>
</font></span> <b><span lang="en-au"><font face="Tahoma" size="2">mike
hodgson</font></span></b><span lang="en-au"><br>
<font face="Tahoma" size="2">blog:</font><font face="Tahoma" size="2"> <a
href="http://links.10026.com/?link=http://sqlnerd.blogspot.com</a></font></span>">http://sqlnerd.blogspot.com">http://sqlnerd.blogspot.com</a></font></span>
</p>
</div>
<br>
<br>
Jim Trowbridge wrote:
<blockquote cite="mid92C390C7-7B08-412E-9053-16C8E295AFBD@.microsoft.com"
type="cite">
<pre wrap="">Books Online does not explain how this runs for SQL Server 2000 (we are on
SP3a).
Does it take any database or other locks at all ? So that it could
contribute to a timeout/disconnect problem we are getting ?
</pre>
</blockquote>
</body>
</html>
--010006090901020804020402--

Auto Stats

Books Online does not explain how this runs for SQL Server 2000 (we are on
SP3a).
Does it take any database or other locks at all ? So that it could
contribute to a timeout/disconnect problem we are getting ?I don't believe so. I think it's unlikely that that is contributing to
any timeout problem, but you can always disable that option (ALTER
DATABASE <dbname> SET AUTO_UPDATE_STATISTICS OFF) and see if the timeout
problem goes away (just do the statistics updates manually (EXEC
sp_updatestats) out of hours).
*mike hodgson*
blog: http://sqlnerd.blogspot.com
Jim Trowbridge wrote:

>Books Online does not explain how this runs for SQL Server 2000 (we are on
>SP3a).
>Does it take any database or other locks at all ? So that it could
>contribute to a timeout/disconnect problem we are getting ?
>
>