Haslett, Andrew
andrew.haslett at ilc.gov.au
Tue Aug 26 22:06:23 CDT 2003
Agree with Access Repl. being flaky, but once set up properly it can be useful. Point taken about security within corporate environment, but still don't understand why an ASP script is preferred over other methods that can do anything that ASP can do and more -> VB, DTS, VBScript etc. Why restrict your feature set to ASP when there is no web interface required and there is no advantage over using HTTP? (Don't get me wrong, I'm a big fan of ASP and use it heaps - but don't see the point when other methods are easier to design, schedule, implement) Cheers, Andrew -----Original Message----- From: Eric Barro [mailto:ebarro at afsweb.com] Sent: Wednesday, 27 August 2003 11:46 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] SQL_Svr BE Access FE Replication with SQL server yes...replicaton with MS Access? Hmmm...well you might want to rethink that. Why run an ASP script? Because the ASP page will run the HTTP post. I don't see why HTTP access to the SQL server back end is a security risk if the web server and the SQL server are on the same LAN segment where only the web server can talk to the SQL server via the listening ports on SQL. --- Eric Barro Senior Systems Analyst Advanced Field Services (208) 772-7060 http://www.afsweb.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Haslett, Andrew Sent: Tuesday, August 26, 2003 6:19 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] SQL_Svr BE Access FE Agree with 1 and 3, but why run an ASP script when no web interface is required. Anything you can initiate with ASP can be done through straight VB code, unless access the the SQL Server BE is limited to HTTP access (bad idea security wise). That said if you are synching databases then the built-in replication systems of both SS and Access should generally be used instead of manual methods. Cheers, Andrew -----Original Message----- From: Eric Barro [mailto:ebarro at afsweb.com] Sent: Wednesday, 27 August 2003 10:15 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] SQL_Svr BE Access FE I would do the following: 1. Access FE on the LAN with Access BE on the same LAN - one for each location 2. VB code that calls an ASP page that talks to a back-end SQL server or even Access MDB in a data center location. ASP page is used to post data to Access MDB at data center location. 3. At night data can be pushed back to the Access MDB at the local site using an FTP download and import process into the local Access MDB This should synch up your DBs. --- Eric Barro Senior Systems Analyst Advanced Field Services (208) 772-7060 http://www.afsweb.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Haslett, Andrew Sent: Tuesday, August 26, 2003 5:03 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] SQL_Svr BE Access FE Replication. Unless you have a *very* high speed WAN connection then your performance will suffer with only a single BE, even with an ADP. One option is to replicate the back-end to each office, however this will obviously have SQL Server license implications, and therefore $$. This is one advantage that Access has, you can replicate the back-ends without cost! (Access replication is a little more flaky than SS though..) If you do have access to a VPN, then I would encourage users to Terminal Serve/Remote Desktop to the location where the back-end is located. This means the only traffic between offices is the screen 'display'. No actual data would be transferred across offices. It also saves you having to distribute front-ends to different offices - you can just maintain a couple of front ends in the one office - ie. one front-end for Terminal Server users, and another for each of the users in that particular office. No replication, no distribution of front-ends. It *will* mean you probably need a dedicated 'Terminal Server' or at least a couple of free machines in that office for users from the other offices to Remote Desktop into. Cheers, Andrew -----Original Message----- From: Stephen R. Zayko [mailto:szayko at secor.com] Sent: Tuesday, 26 August 2003 10:05 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] SQL_Svr BE Access FE Thanks Andrew I am starting from scratch right now. That was the reason for the first post: so that I could start down a path that would have good performance. I also wanted to choose the option that would be the most flexible for me in programming and for the app in future development, add-ons, and changes. As for a web based front end... that is out of the question. Some of the users have had bad experiences with a WB_FE and will not entertain the idea. They like Access, which is good for me! The clients are employees of a medium sized engineering company. They will be accessing the App from each of the ~30 offices throughout the US and Canada. Each office will have one FE for an Engineer or Project Manager to examine status of a job as detailed by input from other Engineers/Geologists throughout the country. Is there a fourth way to connect to a BE data source? -Stephen -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Haslett, Andrew Sent: Monday, August 25, 2003 09:36 PM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] SQL_Svr BE Access FE If you're starting from scratch then an ADP will offer the best performance. You will need to use ADO to interact with the BE which may be a drawback if you are used to DAO. If you already have a front-end then ODBC links may be the best option as it will require very little alteration of existing code / queries etc. You're third option is *basically* what an ADP does, in that it makes ADO calls to SQL Server when required. When you say 'live on the internet' are you talking about your SS BE? If so, then perhaps a web-based front end will offer the best solution. Who are your clients? Where will they be accessing it from? Are you distributing the FE to numerous locations? etc. Cheers, Andrew -----Original Message----- From: Stephen R. Zayko [mailto:szayko at secor.com] Sent: Tuesday, 26 August 2003 10:26 AM To: 'Access Developers discussion and problem solving' Subject: [AccessD] SQL_Svr BE Access FE Dear group: I was wondering if I could get some input for the following scenario: I am writing an AccessXP FE for a MS_SQL Server database that will live on the internet. I was wondering how would be the best way to connect to the data (only I can TRULY answer this question)? But in asking myself that, I was wondering what the pros and cons of each of these are and if anyone has strong feelings one way or another on these: 1) Linked tables via ODBC (using system DSN) 2) Write the FE as an .adp with tables directly connected to server tables 3) Call all connections on the fly to the server where the BE is located 4) Some other way that I do not know about. Most users will have an DSL or T1 connection to the internet. Thanks in advance for your inputs. -Stephen Zayko _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com IMPORTANT - PLEASE READ ******************** This email and any files transmitted with it are confidential and may contain information protected by law from disclosure. If you have received this message in error, please notify the sender immediately and delete this email from your system. No warranty is given that this email or files, if attached to this email, are free from computer viruses or other defects. They are provided on the basis the user assumes all responsibility for loss, damage or consequence resulting directly or indirectly from their use, whether caused by the negligence of the sender or not. _______________________________________________ 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 IMPORTANT - PLEASE READ ******************** This email and any files transmitted with it are confidential and may contain information protected by law from disclosure. If you have received this message in error, please notify the sender immediately and delete this email from your system. No warranty is given that this email or files, if attached to this email, are free from computer viruses or other defects. They are provided on the basis the user assumes all responsibility for loss, damage or consequence resulting directly or indirectly from their use, whether caused by the negligence of the sender or not. _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.509 / Virus Database: 306 - Release Date: 8/12/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.509 / Virus Database: 306 - Release Date: 8/12/2003 _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com IMPORTANT - PLEASE READ ******************** This email and any files transmitted with it are confidential and may contain information protected by law from disclosure. If you have received this message in error, please notify the sender immediately and delete this email from your system. No warranty is given that this email or files, if attached to this email, are free from computer viruses or other defects. They are provided on the basis the user assumes all responsibility for loss, damage or consequence resulting directly or indirectly from their use, whether caused by the negligence of the sender or not. _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.509 / Virus Database: 306 - Release Date: 8/12/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.509 / Virus Database: 306 - Release Date: 8/12/2003 _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com IMPORTANT - PLEASE READ ******************** This email and any files transmitted with it are confidential and may contain information protected by law from disclosure. If you have received this message in error, please notify the sender immediately and delete this email from your system. No warranty is given that this email or files, if attached to this email, are free from computer viruses or other defects. They are provided on the basis the user assumes all responsibility for loss, damage or consequence resulting directly or indirectly from their use, whether caused by the negligence of the sender or not.