Subject Re: Why choose dBASE for new database development? From Mervyn Bick <invalid@invalid.invalid> Date Mon, 27 Jul 2020 19:58:46 +0200 Newsgroups dbase.getting-started On 2020-07-27 00:00, O.J. Newman wrote: > There are many languages/IDEs available today (e.g. MS Visual Studio, > Java/Eclipse, etc.) as well as database prgrams (e.g. MS Access, > R:BASE, etc.) and 4GLs (e.g. WinDev, Clarion). > > Why would dBASE be an excellent choice for a new database development > project? > > Thanks, > O.J. > > P.S. How useful is dmC.R.U.D. in developing real world CRUD > applications? Can dmC.R.U.D. applications be scaled up to a SQL server > backend? > dBASE is much like the Curate's egg.  Very good in parts, not so good in others. If function, rather than cosmetic appeal, is the main concern then dBASE is a very good choice indeed.  It is powerful and very easy to use but the forms can look a bit "frumpy" when compared to others on the market unless the programmer puts quite a bit of effort into the "look". If one wants, say, the more modern look of ribbon menus a la Excel then ActiveX add-ons are available albeit at a price.  Unfortunately not all ActiveX components work with dBASE which can be limiting. The grid control used for displaying a rowset does a good job but it has it's limitations.  Again, an ActiveX control with all the bells and whistles is available at a cost. The form designer is easy to use and a form can be designed very quickly.  The report designer is less intuitive to use but, with a good understanding of event driven OOP programming, there is very little that can't be done. Classes can be subclassed.  External .dll libraries, including the Windows API, can be accessed.  The dBASE User Function Library Project (dUFLP) has about a thousand pieces of reusable code.  A lot of it is not all that useful but there is much code that saves having to reinvent the wheel over and over. :-)  There is a search function but the hardest part is remembering what is in there. One thing that dBASE has and which is not available elsewhere is the "two way" designers.  Once code has been streamed out by the designer changes can be made to the code in the sourcecode editor.  The next time the sourcecode is opened in a designer these changes are reflected in the designer.  This is very handy for an experienced programmer to make quick changes which would hardly warrant opening the form in the designer. The "not so good" part is the data storage.  .DBF files depend on the Borland Data Engine (BDE) for access.  This is VERY old 32-bit technology which imposes definite limitations.  It was "state of the art" when written but, while still usable, the BDE has definitely reached it's "best before" date.  dBase LLC has the licence to use the BDE but they may not change it so none of the shortcomings can be addressed.  A replacement for the BDE has been in the pipeline for many years but dBase LLC is playing this one very close to the chest. That said though, dBASE makes a very good front end to a SQL server. The full power of SQL, not just the limited localSQL subset built into the BDE, becomes available.  I'm retired and I don't develop applications for third parties but all my own little applications either keep the data in Firebird 3 or are in the process of being converted.  I considered using the embedded (one user) version of Firebird but in the end opted to installing the full version of Firebird on my local machine.  This means that all my applications are network-ready if ever the need arises. With the data on a SQL server the approach to reading and writing data is different to the approach with data in .dbf files so changes to the code are needed.  It's not difficult, just different. There have been numerous reports of significant, and unacceptable, slowdowns where more than a handful of users need to access the same data in .dbf files.  I cannot recall any case that was sorted out satisfactorily without having to move the data to a SQL server.  The problem with moving from .dbf files to a SQL server is that it virtually involves a complete rewrite of all the data handling code.  An added problem is that SQL tables need a primary key and this is very often not done in .dbf tables. The problem with using a SQL server to store data is that while SQL is supposed to be standard the actual commands can differ from server to server.  This means a program has to be customised for different servers.  This is, however, not a problem for a new application if one knows up front which server the customer prefers to use.  It also, of course, means that a crash course in a different flavour of SQL may be needed before work can start. :-( When dBASE first saw the light of day back in the mid 1980's there were no dBASE programmers.  The command set was comparatively simple and it was well within the capabilities of the average user to build ad hoc queries from the keyboard.  From there it was a short step to recording regularly repeated tasks in a .prg file.  As users gained experience some realised that their newly gained skill could be used to advantage and we saw developers and authors appearing. Virtually every book seller had a large dBASE section. Over the years dBASE grew and became more powerful but the same basic commands were there and the average user could still manage.  The introduction of objects and OOP changed this to a large extent.  Some critical commands which enabled data entry and display were dropped.  It was still possible for a user to create ad hock queries from the keyboard but now programming required more than just the ability to use the command from the keyboard. It is my personal opinion that the various design Wizards and dmC.R.U.D were created so that users with no programming background could create rudimentary applications.  These tools have their uses and a lot of work has gone into creating them but as far as I'm concerned they are for complete novices.  The Wizards generate code that a beginner could learn from but in my opinion no self-respecting developer would use them. dmC.R.U.D produces a usable form but what you see is what you get.  This may be acceptable for a user but it is unlikely to mesh with the rest of a developer's application. Mervyn.