[AccessD] Front End Updater

MartyConnelly martyconnelly at shaw.ca
Sat May 21 14:08:45 CDT 2005


Just a word of caution ADP's wont run well against SQL Express 2005 
unless you only use SQL 2000
compatibility mode which may turn on the old user connection throttling 
(not sure) and turn off any new features of SQL 2005
You won't be able to create databases, tables, views or any other 
database objects from an ADP.
There is also a possible problem with the switch from SQL DMO to the 
newer SMO.

See
http://blogs.msdn.com/sqlexpress/archive/2004/07/23/192044.aspx
http://lab.msdn.microsoft.com/express/sql/
http://www.tegels.org/qara/

Francisco Tapia wrote:

>On 5/19/05, Arthur Fuller <artful at rogers.com> wrote:
>  
>
>>Let me get your scenario straight.
>>
>>Copies of the app reside on all the local computers.
>>One copy of the latest version resides on some server.
>>A text file resides on the local computers, and contains the version
>>number in standard major/minor form.
>>A text file resides on the server, containing the same info but
>>presumably with a greater major or minot number.
>>A batch file runs, and reads both text files, comparing the numbers. If
>>the server number is greater, the batch file copies the server instance
>>of the app and the text file to the local computer.
>>The batch file then runs the local copy of the app.
>>
>>I have no objections to this scenario. I just want to know if that's
>>precisely what you are saying.
>>    
>>
> 
>In my scenario I built an .exe LiveUpdater after checking out how
>Norton systems do it.  They spawn off another program that acctually
>does the version checking... It was easiest to just create a .ver text
>file to download open it up as if it was an ini w/ the built in API
>calls then check what the .ver file was locally.. if the local copy is
>= or > than that on the server, no big deal, no updates...
>
>In the ADE I use the CurrentProject.Properties (property).  I have a
>custom one called Version (for the ashtetics) and a build( the real
>version)  It does a priliminary check against the .ver file for
>accuracy and then adjusts the .ver so that it is not manually
>manipulated, then launches the LiveUpdate tool, This Tool downloads a
>copy of the new .ver and compares them, if there is a new version of
>the FE then it turns around and downloads that using a wininet call
>from the server.  The neat thing about this kind of call is that I was
>able to sidestep the initall problems w/ the activeX contorl for
>downloading which on occassion would bomb out.  When the new FE
>downloads in the form of a wise.exe file it launches it.  The WISE
>installer checks for a copy of my running application and offers to
>terminate it (this gives the end user the chance to look up something
>quickly or close out right away). After the setup the wise installer
>launches my FE, and the enduser is down for upgrading a mere few
>seconds on the faster P4's or about 1 minute on the slower 400mhz
>Celerons.
>
>So why did I choose to jump this many hoops?... well the application
>I'm working on will eventually become a distributed application that
>will detect the network and choose to connect to the company's Sql
>Server db or the local MSDE (sql server 2005 express).  I needed a
>method to download something of the net quickly enough w/o too much
>overhead.  The liveUpdate tool features a timer and a progress bar
>that allows the end user to simply download my setup file.  I have not
>implemented the distributed portion of the application because quite
>frankly i'm One developer for a system of 90 users :S.  It drives the
>company's failure reporting and now more recently it's Dealership
>ranking systems.  So it continues to grow, and yet I'm still one guy
>:S. (Thanks MAC! <sorry that was just a jibe at an old pal of mine>)
>
>  
>

-- 
Marty Connelly
Victoria, B.C.
Canada






More information about the AccessD mailing list