John Colby
jcolby at colbyconsulting.com
Mon Jun 9 09:21:55 CDT 2003
Roz, Correct, only temporary changes. If the user were to permanently save the changes, wouldn't that cause the next user to see those changes? That would be chaos. Further, it sounds like with 230 potential users all saving their own copies of various reports modified however they wanted, any FE would quickly become an unusable mess. I think you haven't adequately explained to us how the old system worked so we could see what you are trying to emulate. John W. Colby www.colbyconsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Roz Clarke Sent: Monday, June 09, 2003 10:11 AM To: 'accessd at databaseadvisors.com' Subject: RE: [AccessD] AXP Question John True about the conflicts, but these could be handled as even the temporary changes would be getting made to a copy - a copy that would be deleted at the end of the session (unless they decided to keep it). You'd only have to lock the report whilst the copy was being made. Academic anyway as we can't now go back to A97. There are about 20 frequent users and another 230 potential users. We tend to have 10-12 concurrent users in our main reports database at the moment and about 6 at a time in the other 3 but those are largely the same people. Your suggestion is intriguing, but would only address temporary changes, yes? They wouldn't have the option of retaining the new version. It might be good for ad-hoc reporting though. -----Original Message----- From: John Colby [mailto:jcolby at colbyconsulting.com] Sent: 09 June 2003 14:42 To: accessd at databaseadvisors.com Subject: RE: [AccessD] AXP Question Roz, Why could you in A97 and not in AXP? It seems that in a97 you would have had massive conflicts as users tried to open the same report in design view. On a more practical note, how many users are there? Could you have the user run a batch file instead of opening Access directly. The batch file copies the FE to their own directory. They open that copy. Since they are no longer opening it shared, problem solved. John W. Colby www.colbyconsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Roz Clarke Sent: Monday, June 09, 2003 9:29 AM To: 'accessd at databaseadvisors.com' Subject: RE: [AccessD] AXP Question Charles, I envy you. Unfortunately our users must respond to the whims and fancies of our client companies or we will lose contracts. If our client companies were not technophobes we could send csv or xml files and they could arrange their own layouts, but this is the legal industry. They don't understand IT. Also, I have no interest in being obstructive and if they want a different sort order or a certain column heading in bold, why shouldn't they have that? They don't see it as a lot to ask and neither would I - except that we get at least one such request every day, and it's a distraction. As long as they can't get at the logic underlying the reports I'd be more than happy for them to mess with the layouts. I have no more interest in formatting of reports than I do in what colours they use in their Outlook calendars. Of course I am considering other job opportunities but the fact remains that an IT department is a service department, and if we cannot meet requests that, in this circumstance, are quite reasonable, we're not doing our job. With A97, I could have - it's vexing! :) Roz -----Original Message----- From: Wortz, Charles [mailto:CWortz at tea.state.tx.us] Sent: 09 June 2003 14:06 To: accessd at databaseadvisors.com Subject: RE: [AccessD] AXP Question Roz, Users that want constant changes to the layout of reports should expect delays, if not worse! <grin> If they cannot agree on the layout of a report and then live with it until a major change is needed, they should find other employment. <grin> Once I put a report into production, the user has to live with it until the next set of scheduled changes or a business/regulatory rule change. In development, the user can suggest all sort of changes, but once they sign-off on it and it goes into production they must live with their decisions. And higher management is willing to enforce those rules with few exceptions because they recognize IT as a limited and valuable resource. If your environment is different from this, then you may want to consider other job opportunities. Charles Wortz Software Development Division Texas Education Agency 1701 N. Congress Ave Austin, TX 78701-1494 512-463-9493 CWortz at tea.state.tx.us -----Original Message----- From: Roz Clarke [mailto:roz.clarke at donnslaw.co.uk] Sent: Monday 2003 Jun 09 04:08 To: 'accessd at databaseadvisors.com' Subject: RE: [AccessD] AXP Question This makes perfect sense if writing an application that doesn't have to get changed by the users. But consider this scenario: We are building a front end for a data warehousing application (data on SQL Server 7). We need the front end to be flexible as it must provide equivalent functionality to 4 Access databases currently in use, each holding anywhere from 4 - 40 forms and around 100 reports, which are updated & maintained solely by IT (a v. bad thing - we are committed to getting involved every time they want to change the layout of a report, and it causes an overnight delay as we can only write changes into the live database between 12 midnight and 6am. This has the users hopping mad and has resulted in the company failing to meet SLAs with client companies). We have been running AXP for 6 months and they have still not come to terms with the delays. In A97 I would have made the forms & reports flexible by allowing users to a) make temporary changes to objects at runtime, replacing these at the end of the session, and b) copy report objects and make their own changes to the new report. Now I can't. We can't provide each user with their own FE to hold even temporary changes as we are on terminal server. I'm starting to think that Access has become the wrong tool for the job. Any suggestions? Roz -----Original Message----- From: Wortz, Charles [mailto:CWortz at tea.state.tx.us] Sent: 06 June 2003 17:52 To: accessd at databaseadvisors.com Subject: RE: [AccessD] AXP Question Brett, You partition the app and have each developer work on their db. Then if the dbs need to be reunited you have a senior developer recombine them. You are using a configuration management and/or version control tool, are you not? Charles Wortz -----Original Message----- From: Brett Barabash [mailto:BBarabash at TappeConstruction.com] Sent: Friday 2003 Jun 06 11:10 To: 'accessd at databaseadvisors.com' Subject: RE: [AccessD] AXP Question What about environments like ours where you have multiple developers developing in the same development MDB? It was fairly trivial to do this with older versions of Access. -----Original Message----- From: Wortz, Charles [mailto:CWortz at tea.state.tx.us] Sent: Friday, June 06, 2003 11:00 AM To: accessd at databaseadvisors.com Subject: RE: [AccessD] AXP Question As I said in another post, since the dark ages of computing, professional developers have a development version of the application they work on, and the users use a production version of the application. When you are ready to move the development version to production, you follow a set procedure to replace the old production version with the new production version. Only in dire emergencies should a developer have to tinker with the actual production version. And even then, all the users should be out of the application. All the above applies whether the application is in Access, VB, Cobol, SQLServer, VFP, Oracle, etc. I doubt that you can find any software development shop that has been in business for a few years that doesn't follow this model. If you have been developing software for a while, I am sure you follow this model (at least informally) just to keep your sanity. Charles Wortz -----Original Message----- From: Charlotte Foust [mailto:cfoust at infostatsystems.com] Sent: Friday 2003 Jun 06 10:45 To: accessd at databaseadvisors.com Subject: RE: [AccessD] AXP Question Not unwanted by everyone. I'm perfectly happy with that change. Charlotte Foust -----Original Message----- From: ACTEBS [mailto:actebs at actebs.com.au] Sent: Friday, June 06, 2003 7:24 AM To: accessd at databaseadvisors.com Subject: RE: [AccessD] AXP Question Terri, Charles just alerted me to the fact that since the release of A2K, if you use the Shift key to bypass the normal startup, you are opening the DB exclusively. A new unwanted feature kindly supplied by M$... Vlad -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Terri Jarus Sent: Friday, 6 June 2003 10:27 PM To: accessd at databaseadvisors.com Subject: [AccessD] AXP Question I have upgraded a FE database from A97 to AXP successfully, however, a major difference that is annoying me is the fact that in a multiuser environment, I am unable to make changes to the design unless I open exclusively. I never had this problem in A97 and now that my users are all getting upgraded to the AXP FE, I am running across a few areas that need to be tweaked and can't do it until everyone is out of the db. This is a shared network FE. I should probably give everyone their own copy on their desktop, however, this database has evolved greatly over the past 3 years and has required many changes. I have always been able to make these changes while the db was being used by others with no problem. There are about 20 users - so upgrading everyone's FE would be very tedious. I know there are some automated programs to do the updating, but one I had tried took too long and was cumbersome to the user. Any suggestions or ideas - is there a setting I'm missing that would allow design changes while in use??? Thanks for any help. _______________________________________________ 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 _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com