MartyConnelly
martyconnelly at shaw.ca
Tue Oct 7 16:35:05 CDT 2003
I think there is a common distinction problem here. Access is the frontend RAD. JET is the database engine that comes with Access. I can hook Access directly to Oracle or SAP-DB through ADO without touching the Jet database which has problems in a large multi user environment. Without seeing this distinction, you might as well say something like Powerbuilder will have concurrency problems. However if you want to cringe about Access, in the California elections today the Diebold Touch Screen voting machines use a backend access mdb file to collect the votes. Djabarov, Robert wrote: >Ok, John, my list is a little longer and includes cobol for vms, as/400, >and os390, plus visual dbase, foxpro (2.0) all the way to visual foxpro, >jcl, rexx, clarion, java, ... That's about it. Every single tool was >used to create at least one production routine. Many are still running >the same code (cobol, clarion, paradox - converted to win version, and >of course vb) with no maintenance. There are 2 commercial applications >that have been purchased and are being used in three states... Is it my >cover letter or a job history section? > >C is not a RAD tool, but C++ or Delphi is, needless to say vb, providing >it's in a shop that has been specializing in development using that tool >for a while. > >I am pretty sure you can crank up an app in 12 hours using access! How >big is this app? How many users (concurrent) does it have? Using >access for multi-user environment is a cuicide and a guaranteed call >from a recruiter saying "sorry you lost your job, but my client decided >to fill in the position internally." > >I will not even attempt to compete with you to beat a 12-hour dead-line, >but I will develop something like this probably in a week and a half. >Slow? Yup, but it will be solid and will not depend on the number of >users to continue to perform the same way. I also bet that your access >solution will croke up after the 6th user joins your access party. >Speed of development is not everything, though is one of the major >contributing factors. > >And I will take my hat off to you should we meet face-to-face, simply >out of respect to your experience. > >But please, don't call access a RAD tool. It may be viewed as a >prototype tool, but not anything further. > >-----Original Message----- >From: dba-sqlserver-bounces at databaseadvisors.com >[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of John >Colby >Sent: Tuesday, October 07, 2003 12:28 PM >To: dba-sqlserver at databaseadvisors.com >Subject: RE: [dba-SQLServer]ODBC connection - Is this normal > > >Robert, > >I have programmed since the 80s, using Fortran, C, Turbo Pascal, VB, >DBase XX, Paradox, Access etc. Access is in no way even remotely >equivalent to any of those other tools. Access is a tool just like C#, >C++ or even VB. Access was designed, from the ground up, to build >databases and the application to use the databases. C, and later C++ >was designed, from the ground up, to give you gnats ass control over >hardware. It was designed to do what assembler allowed, but from a >higher level. VB was designed to replace Fortran as a general purpose, >easy(ier) to use language for general purpose programming. > >Anyone who makes any attempt to claim that C or ANY of it's variants is >a RAD database development tool appears to ME to fall into that circle >where people ask others to flog them so they can enjoy the pain. > >Using JUST Access I built (last week), from the ground up, a database >with 20 tables, 19 relationships, enforcing referential integrity, 16 >forms, including tab forms displaying child records to one of the >tables, combos that provide pick lists from the list tables etc. etc. >ALL of that took ~12 hours. > >If you claim that you can do that in C, C++, C# or VB I will: > >a) Take my hat off to you OR... >b) Call you a liar to your face and challenge you to do so in front of >me. > >Probably the latter. I can do this in front of you BTW (assuming we can >meet face to face). > >So... > > > >>Wow, so choosing the right tool for the job is as bad as body piercing, >> >> >whips and chains? > >NO, choosing the WRONG tool for the job is the equivalent of body >piercing, whips and chains. > >And further, I was making a joke, so lighten up a bit. > >John W. Colby >www.colbyconsulting.com > >-----Original Message----- >From: dba-sqlserver-bounces at databaseadvisors.com >[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of >Djabarov, Robert >Sent: Tuesday, October 07, 2003 9:43 AM >To: dba-sqlserver at databaseadvisors.com >Subject: RE: [dba-SQLServer]ODBC connection - Is this normal > > >Wow, so choosing the right tool for the job is as bad as body piercing, >whips and chains? AND, you dare to call it "framework"????? >"On-The-Fly SQL Statements"???? Man, I must be missing something very >simple, and wasted all my life not being able to see it...wonder what >the heck it is... Oh, I get it, it's MS Access used as a RAD tool!!!! > >Good luck > >-----Original Message----- >From: dba-sqlserver-bounces at databaseadvisors.com >[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of John >Colby >Sent: Tuesday, October 07, 2003 2:17 AM >To: dba-sqlserver at databaseadvisors.com >Subject: RE: [dba-SQLServer]ODBC connection - Is this normal > > > > >>>Very normal. It's also normal to drop Access as your FE and do >>> >>> >everything using something more robust like C#, C++, or even VB. > >Yea, in the same circles where it is normal to tie each other up, pierce >body parts and use whips and chains for sexually deviant purposes. > > > >>Or even abandoning the .mdb part of Access and building it as an ADP, >>then >> >> >that problem goes away completely and you still retain some of the RAD >attributes of building it w/ Access. > >True. And for those of you who don't use a framework, or who designed >their framework from the ground up to use SQL Server that is certainly >an option. My framework does things not easily ported to SQL Server >(on-the-fly SQL Statements referencing form controls for example). One >of the reasons that I moved my billing app to SQL Server is to slowly >start the process of porting the framework. To this point, life has >gotten in the way of THAT project. > >John W. Colby >www.colbyconsulting.com > >-----Original Message----- >From: dba-sqlserver-bounces at databaseadvisors.com >[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of >Francisco H Tapia >Sent: Tuesday, October 07, 2003 1:10 AM >To: dba-sqlserver at databaseadvisors.com >Subject: Re: [dba-SQLServer]ODBC connection - Is this normal > > >Djabarov, Robert wrote: > > >>Very normal. It's also normal to drop Access as your FE and do >>everything using something more robust like C#, C++, or even VB. >> >> >> > >Or even abandoning the .mdb part of Access and building it as an ADP, >then that problem goes away completely and you still retain some of the >RAD attributes of building it w/ Access. > > >-- >-Francisco > > >_______________________________________________ >dba-SQLServer mailing list >dba-SQLServer at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >http://www.databaseadvisors.com > >_______________________________________________ >dba-SQLServer mailing list >dba-SQLServer at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >http://www.databaseadvisors.com > > > > -- Marty Connelly Victoria, B.C. Canada