Jim Lawrence
accessd at shaw.ca
Thu Feb 14 19:43:17 CST 2008
Hi Drew: First: Thanks so much for all that information as it gives me confidence on the available choices and direction to take. Second: Your situation, access, control and opportunity to enjoy such a challenging project is enough to make my mouth water. Jim -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka Sent: Thursday, February 14, 2008 4:32 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] MDB on the web Continued with >>>in-line reply -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, February 14, 2008 5:24 PM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] MDB on the web Hi Drew: <snip> Is there any reason why only MDBs have been used, other than "If it ain't broke don't fix it"? >>>#7. Interface: While I have a lot of web interfaces, there are times where I might need to whip up a report, query, or even a form (I use code behind forms quite frequently to do data manipulations....not that I do data manipulation frequently, but if I have to manipulation, I may use a query, but most of the time I need some capabilities that only VBA has). Since I use .mdb's, to create a one time or infrequent report, all I have to do is open the .mdb off of the intranet/internet server and make the report. No other steps required. Would you have any other suggestions or recommendations? >>>Yes, first of all, I have listed many of the reasons why I use .mdbs, but NONE of them should be taken as a 'don't use a server side db' argument. As a member of our IT department, I don't have to deal with the stigma of 'Access is a toy'. Believe you me, with the number of things I have done with Access based systems, no one at my company would challenge me on the capabilities of Access. There are absolute circumstances where Access won't cut it though. I have an upcoming system which I'll detail for the heck of it in a minute, which is going to REQUIRE a SQL Server. It's just that until recently, I haven't had a project that required more then Access could provide. Many IT departments challenge the reliability of an Access .mdb. Well, go visit our website. http://www.marlow.com . The navigation bar you see on EVERY page is built with a combination of two databases. One's an .mdb, the other is a .dat file created by FrontPage (it's where it stores it's navigation data). But every single time you go to any page on our website, our IIS server is reading that dat file, and also querying an .mdb to create that menu bar. (it queries the product database, to build the product links on the menu bar). It's fast, and our web server is running on a PIII 800 mhz machine, with 384 megs of RAM, so it's not a screaming machine, but it runs fine. Now that's 'reading' a database. That same site records its IIS logs in an Access .mdb. Which means, for every hit on our site, the IIS server is dumping several records into an .mdb PER HIT. (Because every image displayed on a website is a single entry in the web log). We've had that site online going on 5 years....not a single .mdb on that server has ever corrupted. As for the system I am building that will require a SQL Server. It's a Data Acquisition system. We have lot's of test machines (computers using engineering cards, or serial interfaces, to record test data on the stuff we build). All of these machines record data in various ways, most of them into .mdbs that the system developers created. These databases are not designed very well, in 99% of the cases, the database has one huge flat table that holds whatever data they are recording. A few years ago, I was asked to build a database to record data for a specific machine. I went one step more there. I build an .mdb that is designed to allow the 'system developer' to create his own 'tables' (I think I called them programs) where he can see this 'program' what fields he will need, including the type of field (date, integer, double, text, etc), limits on the field (min max) and 'warning levels' (min max), etc. The system doesn't create a new table, it is just designed that these 'programs' are stored within it's structure, and then the data is stored in separate tables (based on the data type). It's as normalized as I could get it. Up until this point, I have completed, and it's running on that particular test machine (and has been for I think 2 years). It has a web interface....and that's part of the beauty of this system. Currently, our engineers hit these other test machines and to get the data from their .mdb's, they are opening those .mdb's across a network connection. With the system I created, the 'web interface' is run on the local test machine. So data from that test machine is actually queried BY the test machine. (VERY fast way to view that data). What I have to 'finish' now with this system, is that I am going to create a SQL Server database that will be a central hub where all data, from all test machines is dumped into it. It will simply be too much data to keep an in .mdb. Then I will build a web interface that will allow our engineers and anyone else that needs access to this data, to view all of the data. If they are reviewing data that is a day old or older, they would be seeing the data from the SQL Server, if they want to see the live data, they would actually be redirected to those machine's IIS servers. I know this has very little to do with what you're doing, but I don't have many venues where I get to chat up about systems I build (at least not with having the listener understand what I'm talking about!). Drew The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI BusinessSensitve material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com