[AccessD] Testing SQL Server linked FEs

Dan,

Are these parallel systems physical servers, installed instances of SQL Server or databases?  It 
sounds like you are talking about databases.

John W. Colby
Colby Consulting

Reality is what refuses to go away
when you do not believe in it

On 2/17/2012 1:25 PM, Dan Waters wrote:
> I have parallel systems: Production, Test, and Review.  Test is just for me
> to do usual test stuff.  Review is for users when they want to look at a
> change I've made so they are certain it works like they wanted it to.
>
> In SQL Server, prior to using either Test or Review, I make a backup and
> then restore that backup as DatabaseTEST and DatabaseREVIEW.  Each different
> access app file has ODBC links which point to its respective database in SQL
> Server.
>
> Each system has its own Config.mdb file, which holds the path for the table
> links.  If I'm done testing, I can copy the FE.mdb file from the Test folder
> to the Prod folder.  Part of the startup code is to check to see if the
> table links in the FE.mdb match what's in the Config.mdb file.  If not, then
> a procedure to redefine the .Connect property of the table links is run.
>
> I have this same setup for each customer on their server, which I can log
> onto via VPN/Remote Desktop.
>
> HTH!
> Dan
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
> Sent: Friday, February 17, 2012 11:29 AM
> To: Access Developers discussion and problem solving
> Subject: [AccessD] Testing SQL Server linked FEs
>
> To this point I have always worked with MDB data stores.  When I did testing
> where I needed to modify data (adds/ deletes / edits) I would copy the BE
> files to a local directory and then map that local directory to the X: drive
> where all the links pointed to.  Voila, "test mode".
>
> Obviously that doesn't work with links to SQL Server.  I have seen code for
> modifying the link info of the tabledef, storing the server / database info
> in a local table in the FE.  That seems like one solution.  Is anyone doing
> something like this?
> --
> John W. Colby
> Colby Consulting
>
> Reality is what refuses to go away
> when you do not believe in it
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>