[AccessD] How to work Offline with SQL Server

Rusty Hammond rusty.hammond at cpiqpc.com
Fri Jan 8 16:24:02 CST 2010


Ahh.  To keep them in sync structure wise, you can script the database,
then run the script on the test db to create all of the tables, views,
stored procs, etc..  This basically requires blasting away the current
version and creating a new one.

If you want to keep the database intact and just make changes to make it
match, you have to write your own sql scripts that will modify the
objects in your database.

Is that what you needed? 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Friday, January 08, 2010 3:59 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] How to work Offline with SQL Server

In this specific case I remote desktop directly into the server and work
on that.  I am really asking "how do you keep the test and dev database
in sync" at least structure wise.  Using the mapped drive / mdb it is
trivial to just copy the back end be to the local drive.  That also gets
the latest data.

John W. Colby
www.ColbyConsulting.com


Rusty Hammond wrote:
> If the database is large then we have a separate test server we use.
> For smaller databases, we've used the free SQL Server Express and 
> installed it on the developer's machine - so the database is on the 
> local machine for testing.
> 
> 
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
> Sent: Friday, January 08, 2010 3:05 PM
> To: Access Developers discussion and problem solving
> Subject: [AccessD] How to work Offline with SQL Server
> 
> When my clients use Access MDBs for the data store it is a trivial 
> matter to set up mapped drives, and then link live / offline.
> 
> 1) Create a "live data directory" and store the live data be in that.
> 2) Share that and map it as the X: drive on the workstations.
> 3) Link the FE to the BE on that mapped X: drive
> 4) Create a dev directory on my dev machine.
> 5) Share that.
> 6) Create a batch MapLive.Bat file that maps the Live directory as X:
> drive.
> 7) Create a batch MapLocal.Bat file that maps my local share as the X:
> drive.
> 8) Run MapLocal when debugging.  Any changes to data is written to the

> local copy of the BE on my hard drive.
> 9) Run MapLive when updating live data.  Any data changes written to 
> the live database.
> 
> So, how do I achieve the same flexibility using SQL Server?  In this 
> case the data resides in a database on a server.  In order to have the

> same kind of isolation from test to live I would have to maintain a 
> mirror of the database somewhere.  It seems rather unwieldy.
> 
> Does anyone do this kind of thing using SQL Server as the data store?
> --
> John W. Colby
> www.ColbyConsulting.com
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> **********************************************************************
> WARNING: All e-mail sent to and from this address will be received, 
> scanned or otherwise recorded by the CPI Qualified Plan Consultants,
Inc.
> corporate e-mail system and is subject to archival, monitoring or 
> review by, and/or disclosure to, someone other than the recipient.
> **********************************************************************
> 
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
**********************************************************************
WARNING: All e-mail sent to and from this address will be received,
scanned or otherwise recorded by the CPI Qualified Plan Consultants, Inc.
corporate e-mail system and is subject to archival, monitoring or review 
by, and/or disclosure to, someone other than the recipient.
**********************************************************************




More information about the AccessD mailing list