MartyConnelly
martyconnelly at shaw.ca
Fri May 13 12:11:12 CDT 2005
I store the current version in Visual Source Safe. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W. Colby Sent: Thursday, May 12, 2005 8:58 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Front End Updater Simplicity. My clients typically have 30-40 stations max, and the FE takes a few seconds to load. A batch file took about 3 minutes to cook up and just works. Obviously if this is going to a system with hundreds of workstations then something else would be in order. The other thing is that by downloading a fresh copy every time they open the FE I can do temp tables without worrying about bloat. John W. Colby www.ColbyConsulting.com Contribute your unused CPU cycles to a good cause: http://folding.stanford.edu/ -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Kath Pelletti Sent: Thursday, May 12, 2005 8:45 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Front End Updater I can't see either why you would want to download the FE every time. I always do a check on startup and replace only if the version no. has changed. Kath ----- Original Message ----- From: Francisco Tapia To: Access Developers discussion and problem solving Sent: Friday, May 13, 2005 10:21 AM Subject: Re: [AccessD] Front End Updater That still sucks, the updater I put together checks the ver through the day (about once every hour), a small tiny file less than 1k, that's not a big deal but if I was gonna incorporate wan, i'd slow the check to once on boot up of the software and once per day (if they never shut down). having to dowload whatever the FE size is every time you wanna use the application makes it feel clunky. On 5/12/05, John W. Colby <jwcolby at colbyconsulting.com> wrote: > > On a local lan I just have a batch file that does the download every time > the user loads the FE. Over a low speed wan this might be problematic, > though over a high speed internet connection it would probably work just > fine. > > John W. Colby > www.ColbyConsulting.com <http://www.ColbyConsulting.com> > > Contribute your unused CPU cycles to a good cause: > http://folding.stanford.edu/ > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller > Sent: Thursday, May 12, 2005 2:52 PM > To: Access Developers discussion and problem solving > Subject: [AccessD] Front End Updater > > I know that this has been kicked around several times in the past, but > I'd like to know the current thinking on this subject. Given N users on > a LAN (and it might be a WAN), we want to place any updates in one > standard place (probably using a hardcoded reference to the box and dir) > and then have a mechanism that checks to see if the update is more > recent than the version locally loaded. > > What puzzles me about this is: given Access's habit of re-timestamping > the ADP/MDB file upon loading, how do you compare versions to see which > is more recent? A laptop user, for example, currently disconnected but > going to be connected tomorrow morning, may have a more recent timestamp > on her file than the one on the net. How do you get around this problem? > > TIA, > Arthur > > > > > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.11.9 - Release Date: 5/12/2005 > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More... -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com Longhorn and the future of printing in Windows References: <A5B5AA20555F594BA7B6BD2048E49E4376F876 at m-niosh-5.niosh.cdc.gov> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Given the struggles with printers and deployment, I have seen here, I thought I would pass this post on, there is relief in sight, but don't hold your breath. It might be of interest to those doing long term development. But I haven't seen Access running on Longhorn yet. In addition to post below there is also this Enterprise Printing With Web Services coming with Longhorn: Problem: Never had the ability to know when job had actually completed Can’t trigger activities based on job completion Don’t know the status of job beyond being sent to the spooler Solution: Rich eventing mechanism with (WS-Eventing) Benefits: True end of job Richer error reporting with real time device status Restarting unfinished jobs from PC in exactly the right place This post is from a print spoooler software company. Merrion Computing. A good site for VB Printer software code. Date: Wed May 11, 2005 8:10 am Subject: Longhorn and the future of printing in Windows The next version of Windows (codenamed "Longhorn") features a very radical overhaul of the printing subsystem which may well be of interest to developers working with printer related applications. [1] Metro Printing "Metro" is a new standard for the document / spooler files that is based on XML and is extensible. Using this format means that in the future all printed documents will be stored in a format that is human readable and not device dependent. This means that all the problems with transfering documents from one print device to another will be a thing of the past. [2] Universal file display format Since all applications that print on Longhorn will be spooled to this new format and since this format is open it means that document viewers (like the MS Word viewer or PDF) will no longer be needed. Instead press print, print to a file and send the file to the recipient (or publish it on the internet)... Longhorn and Metro references: There are a number of documents on http://www.microsoft.com/whdc/device/print/default.mspx that are useful to developers wanting to get a head start on Longhorn printing. I have downloaded them and will be writing up articles/posts about specific parts...and the implication for printer monitoring applications in the future. I don't see a free print accounting module being added to the native OS but mainly for legal reasons (MS are particularily anxious to avoid the trouble that they had with the E.U. over bundling the free media player) However the changes mean that it will be a lot easier to write more sophisticated document handling and accounting applicatiosn and I would see a number of third party providers (including ourselves) doing just that. One of the greatest opportunities from my point of view is that it will be possible to write components that plug in to the print path in any CLR language (VB.Net, C# etc.) I am angling to get a new development machine specifically for various beta products (SQL Server 2005, Longhorn and Visual Studio 2005) and will post up any code related to this that is of general use. Hope this is helpful, Duncan Jones Merrion Computing Ltd http://www.merrioncomputing.com Post message: MerrionComputing at yahoogroups.com -- Marty Connelly Victoria, B.C. Canada