Jim Dettman
jimdettman at earthlink.net
Mon Feb 9 18:14:29 CST 2004
Bruce, <<Secondly, the so far unsubstantiated rumours of the death of the Jet engine. Now it seems imminent unless Getz hasn't been too diligent on his confirmation of rumours.>> Well just in case you missed it, JET is officially dead. No new versions are planned and DAO is frozen at release 3.61. Is it still around? Certainly. Will it still be around for years? Yes. Can you still use it in a new app? Yes. Would you? Sure (depending on the app). But will we see any new features? No. Will you still see "official" support in a few years? No. That's what I would call dead. << And while were on that topic..... where does he get off saying that a general purpose O/S level file management system is a better idea than a specifically tailored and tuned rdb query engine?>> I guess that would depend on the file system wouldn't it? And while JET may be a "specifically tailored and tuned rdb query engine", it stinks when it comes to stability over a network. It's very sensitive to network timeouts and generally complains long before any other network app does. Jim Dettman President, Online Computer Services of WNY, Inc. (315) 699-3443 jimdettman at earthlink.net -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of bruce_bruen at mlc.com.au Sent: Monday, February 09, 2004 6:29 PM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Next Version of Access 12 Musings on what might happen(RANT) (Please do not take this as a statement of diminution of Access applications) <RANT level=4> In the last 10 or so years I have developed, I suppose, in excess of 200 Access databases in the course of my work. None of these of which I speak are "commercial multiuser business applications" ( I have developed and maintained several of these as well). These databases have varied in size of one to hundreds of tables, zero to dozens of forms, zero to dozens of reports, been used by one to (in one case) 62 concurrent users and have had between zero and several thousand lines of code. They have been single tier, FE/BE, FE/multiple BE and have contained linked tables, have used foreign desktop rdbms (FoxPro, BDE, MSDE) and foreign server RDBMS (SQLServer, Oracle, Sybase, MySQL) data linkages. I have loaded and unloaded probably tens, possibly hundreds, of millions of data rows from text files, web pages, mail clients, spreadsheets and even DB2 databases into and out of these databases. Why? I am a consultant in information management. I often deal with large sets of data, often with very complex relationships or with rapidly varying relationships. Occasionally we have needed to develop vast test databases containing synthetic or at least extremely disguised data. Sometimes I have needed to explore a particular information factor with a client that involves an extremely simple demo dataset, for example to show a small businessman how (i.e. the technical details) he could use a secure website for his "top" customers to place orders and track production. I turned to Access at Ver 1.0 when we needed to generate a set of 200,000 futures trades as test data. The choices were to do it in Excel, get a programmer to do it in VBasic(? memory fails me) or try and do it ourselves. The Excel route was discounted as we couldn't get the statistical profiles needed for the trade flow across the whole series due to the row limit. So I thought it was about time I learned how to use this new fangled database thingy. At that time I had a fairly good rdb skillset, some experience in "playing" with the Access front end - forms and queries etc but no access basic expertise. I completed the 200,000 row profile we needed in 16 hours. Furthermore, we also had the ability to vary the profile and regenerate the dataset in minutes. The Basic programmer had quoted me 5 days to do the job as a single shot exercise. Three years later I heard that the exchange was still using the database to generate test data - the profile changing with every new commodity added to the floor. Since then I have used Access in just about every contract I have had. >From data quality reviews, security reviews, information restructuring assignments through to prototype GUIs, prototype databases and even in process controllers and business management anlyses. The beauty of Access in my environment lies in its immediately accessible power - build your solution and its deployed. End of story. It saddens, if not infuriates me, that Microsoft and these industry "pundits" have for several years been promoting the demise of Access, the Jet engine and the brilliant desktop analytic toolset contrived by the originators. First off, the bloody "murder" of DAO. Amusingly denied by MS publications wherein they stated that DAO was still the best direct access method for JET and would remain so. Now, totally unsupported. I dont "need" the features offered by ADO. My data, when I'm working with it is all within the Jet database, all readily and efficiently accessible thorugh DAO. I am not trying to build a massive, scalable, one size fits all application using a desktop database. I need a tool that lets me do sophisticated manipulations of large amounts of data in a desktop environment. DAO wasn't broken, so they made it extinct. Secondly, the so far unsubstantiated rumours of the death of the Jet engine. Now it seems imminent unless Getz hasn't been too diligent on his confirmation of rumours. And while were on that topic..... where does he get off saying that a general purpose O/S level file management system is a better idea than a specifically tailored and tuned rdb query engine? I presume Getz prefers the bus to a Ferrari as well. Anyway, to get back to Jet. Now I willl grant that, at times, I have resorted to hevier duty engines for speed reasons on more complex analyses. But in the main the Jet engine has provided all the speed needed, and also some very sophisticated query handling. So why does MS need to get rid of Jet? I just dont understand the mentality in this type of thinking. Is it "its just a desktop database" and the MS marketers want to be mainframe programmers? Is it, "Access is just a toy incapable of serious application"? HAH! Finally, THE EXCRUTIATING AGONY of forms design and data binding in VS and VS.net compared to Access, leaves me strangely nausious in the light of statements such as "It's unclear at this point how well-integrated with Visual Studio the Access designers might be". I would think totally disconnected and never to be considered might be the better approach. To me then, these furphy's being propogated by Getz (and I do not know how well connected he is,and therefore how much weight to assign them) are dangerous and belittling to a great product. It isn't a matter of jumping on the "technology revolution" bandwagon. I dont want to be "left behind with obsolete skills". So take a letter Miss Simth, Dear Bill, The Access tool is damned fine now, thanks very much. Squeaky clean, well oiled and working well. Please dont let the kids play in it. yours etc.. Bruce p.s. Stuart McLachlan's comment about calling this new pancea DDE had me definitely smiling. I well recall the MS marketspeak that went with COM/DCOM had a melody line very similar to Box's/Loney's statements. I think Microsoft's intentions are very clear. .NET and XML-based services are the future. COM is dead. The current Access platform is dead. ...<snip>... That leaves only smart, data-aware forms as Access's last, best feature. But Getz is now enthusiastically talking about getting rid of that, too. It seems clear to me that, whatever it may be called, the next major version of Access will be a replacement, rather than an evolutionary change. Microsoft has given us the courtesy of advance notice, along with about two years to make a smooth transition. I, for one, do not intend to be caught with outdated skills when the current Access becomes obsolete. -Ken _______________________________________________ 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