************************************* * * * DB/C Newsletter * * October 1995 * * * ************************************* Editor's Notes DB/C 9.0 has not been released. It will continue to be available in beta test form through November 30. We are hopeful that we will be able to release DB/C 9.0 on December 1. Snow Software, the maker of Snow Reporter, has announced support for DB/C data and index files. You can contact them at (813) 784-8899 or by FAX at (813) 787-1904. An error in the July Newsletter has been brought to our attention. The following sample code was included in the article titled "GUI Features New in DB/C 9": ICN RESOURCE BAR RESOURCE PREP ICN, "icon=start, h=16, v=16, colorbits=4, pixels=": "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF": "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFAAAAFFFFFFFFFFFFAAAAFFFFFF": "FFFFFFAAAAFFFFFFFFFFFFAAAAFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF": "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF" PREP BAR, "toolbar=maintool, pushbutton=1:start:Start Engine,": "pushbutton=2:stop:Stop Engine" Both of the PREP statements will not compile in the current beta version of DB/C 9.0. This is because colon-continued lists are considered to be the equivalent of comma-delimited lists, which implies that there are multiple operands after the first operand (in this case the RESOURCE variable). The syntax of PREP with a RESOURCE or DEVICE as the first operand only allows one additional operand. Here is one correct way to write the same code: ICN RESOURCE BAR RESOURCE ICNDEF INIT "icon=start, h=16, v=16, colorbits=4, pixels=": "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF": "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFAAAAFFFFFFFFFFFFAAAAFFFFFF": "FFFFFFAAAAFFFFFFFFFFFFAAAAFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF": "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF" BARDEF INIT "toolbar=maintool, pushbutton=1:start:Start Engine,": "pushbutton=2:stop:Stop Engine" PREP ICN, ICNDEF PREP BAR, BARDEF This month's article attempts to answer the question - 'Why should I use DB/C?'. Several people have asked that question in the last few months, so I assume other readers are also interested in our answer. We feel that there are several important reasons to use DB/C. This month's article elucidates these reasons. don.wills@swc.com Why Use DB/C? There are many factors that differentiate DB/C from other programming languages and environments. These factors fall one of several categories. Here are the categories: 1. Unsurpassed portability 2. Appropriate for business applications 3. Excellent performance 4. Programmer convenience; ease of programming and maintenance 5. Special features available without coding in C 6. Various other reasons The single most important design consideration for DB/C is portability. Subject, Wills & Company created DB/C to be independent from Datapoint Corp. But, instead of just choosing another operating environment to run on, we made the decision to adhere to this philosophy: We will never again be dependent on a single hardware or software vendor. It didn't matter whether that vendor was IBM or any other. Independence was primary. DB/C runs today on MS-DOS, Windows, all of the UNIX variants, Mac OS, OS/2 and DEC VMS. Unfortunately, it is technically impossible to run on IBM mainframes or AS/400s. If it were possible, DB/C would be available for these environments also. Ten years from now, programs that exist today will be running on hardware and software systems that don't exist today - maybe even from companies that don't exist today. An interesting fact is that DATABUS was in wide use before Microsoft even came into existence. DATABUS will continue to exist for many years to come. And with DB/C, you can be assured that your software will run on all of the popular operating environments. From the DATABUS roots of the early 1970's and continueing today, the target market for DATABUS is applications developed for businesses. For example, ISAM and fixed decimal arithmetic are fundamental concepts in the language. Some languages that are used today in business environments still don't have these concepts as basic features of the language. With it's roots in desktop computers, DATABUS programs always had to be efficient to provide reasonable response time. The language was designed with performance as an important criteria. Today's DB/C language upholds that tradition. DB/C applications run quickly and efficiently in all of the environments that are supported. An example of the difference in efficiency is the contrast between the DATABUS file system and SQL. DATABUS was designed to run well on existing computers. SQL was designed to meet E.F. Codd's definition of a relational database, without regard to the reality of computing resources. The same application will require much more processing power when written using SQL as compared with the DB/C file system. In addition, many features important to business applications are not available in traditional SQL, because they don't meet the strict definition of 'relational'. Many of these features have been added by various SQL vendors, but they are not universally available and in some cases are incompatible. With regard to programming convenience, DB/C is unsurpassed. Large programs compile in a few seconds. On faster machines, compilation is almost instantaneous. There is no linker. The source debugger is integrated with the run-time and is easy to invoke with just a single keystroke. The language is strongly typed, which makes the programmer's job less error prone. Fixed decimal variables can never be corrupted to contain invalid data. Array indexes are always automatically checked for validity. Address variables cannot point to invalid data or data of the wrong type. Memory can not be accidentally overstored. Standard source code control systems can be used. And finally, programs are easily readable because of the use of words instead of symbols. Verbs with names like WRITE, DISPLAY and PRINT do exactly what the programmer expects them to do. DB/C applications can be written much more quickly, with a much higher chance of success, than applications written in other environments. There are numerous examples of 4GL/SQL applications that were never finished, but consumed millions of dollars before being abandoned. That doesn't happen with DB/C. There are many features inherent in DB/C that are unavailable in other languages without resorting to writing C programs. Some of these features are: access to serial ports (such as COM1: in MS-DOS), execution of other programs (with the ROLLOUT and EXECUTE verbs), read/write of any type of file (using the BINARY option), and direct access to system print spoolers. In the other reasons category, we feel that technical support is a very important aspect that differentiates DB/C from other programming languages. From our personal telephone support to our Internet presence, we believe that support is critical to everyone's success. We realize that Microsoft offers programming languages competitive with DB/C - specifically Visual C++, Visual Basic and Visual Foxpro. DB/C looks very good when compared feature by feature with each of the Microsoft Visual languages. The tendency for most people is to say "but it's Microsoft". Remember - 10 years ago IBM was at the top of the hill, but now most people think IBM is lost when it comes to programming languages. Programming languages are a very small part of Microsoft. Microsoft's future growth market is the home market, not business application developers. With DB/C's support for SQL and GUI, there is no impediment to migrating from existing ISAM and character-based applications to GUI and/or SQL-based applications without having to rewrite your system. And for new development, DB/C is a cost effective, easy to maintain way to get your application written quickly and correctly. DB/C Class Schedule The next DB/C class is not yet scheduled.