Frequently Asked Questions

Last updated September 2, 2004

General Questions

  • I'd like to find out the version and license information about DB/C FS or DB/C DX.
  • I can't seem to get the file path feature of DB/C DX or DB/C FS working. What am I doing wrong?
  • DB/C Programming Language Questions

  • Why do we get an E 506 error when executing SCRNREST on some computers but not others?
  • How do you pass parameters from the command line into a DB/C program?
  • What is the use of the ISNULL operator?
  • What is the purpose of disable and enable statements?
  • How can I convert DB/C programs to use SQL instead of DB/C files?
  • How do I test for 'control has changed' on PANELs and DIALOGs?
  • We have a problem with the syntax of SQLEXEC when data contains a string of characters like "ABC:152". This causes the SQL interface of DB/C to attempt to replace ":152" with the value of the 152nd parameter in the SQL list. How can we avoid this problem?
  • With the SQL interface of DB/C DX (SQLEXEC), can I make two concurrent connections to different SQL databases?
  • DB/C DX Questions

  • When I launch the version 13.1 DX runtime on some Windows machines, I get an error message, 'A required .DLL file, ODBC32.DLL, was not found'. Why do I get this and what can I do?
  • How do we create customized DB/C DX configuration file for each user?
  • Why do we get random data corruptions and runtime errors I1751, I1753 and R 301 when running DB/C on a local area network?
  • Why can't I display a character in the lower right corner of the screen when using DB/C in UNIX?
  • Why can't I gray out tabs in a GUI panel or dialog?
  • Is there a decompiler to recreate program source files from .DBC files?
  • Why do we occasionally get I 602 errors running on Windows NT workstations?
  • Why does performance suffer using a 64Kb lease line?
  • How is memory allocated in UNIX?
  • Can I get around the file size limit in the EDIT utility?
  • Our package software is sold on a per user basis. Can the DB/C DX user counting mechanism be changed to increment by one user instead of 5, 10 or 20 users as it now works?
  • DB/C FS Questions

  • When using the Microsoft ADO interface to access files managed by DB/C FS 2, it seems that the column description from the DBD file becomes the column name. How can we get around this?
  • Why can't I start the NT version of DB/C FS from the command line when it's installed as an NT service and the service is stopped?
  • When attempting to access a DB/C FS database from certain query tools like Crystal Reports and Microsoft Access, this error message occurs: [SWC][FS2 ODBC Driver]NAME is invalid
  • When using DB/C FS, why does my Microsoft Access query take so long?
  • How does the locking mechanism of DB/C FS work in conjunction with FILEPI and record locking in DB/C DX?

  • General Questions


    Question:

    I'd like to find out the version and license information about DB/C FS or DB/C DX.

    Answer:

    Start dbcfs, dbc or dbcc with the -? command line option.


    Question:

    I can't seem to get the file path feature of DB/C DX or DB/C FS working. What am I doing wrong? Here is an example:

    dbcdx.file.open=C:\USER\DATA1

    Answer:

    The back slash character (\) is the escape (or forcing) character for all properties files. The correct way to specify the line in the example is:

    dbcdx.file.open=C:\\USER\\DATA1

    DB/C Programming Language Questions


    Question:

    Why do we get an E 506 error executing the SCRNREST verb on some computers but not others?

    Answer:

    The size of the character variable required to store the screen information varies depending on the size of the screen and operating system in use. In the past, almost all screen sizes were 80 characters wide by 25 lines. However, in Windows, the user can set the size of the console to be various larger sizes. DB/C DX senses the larger screen size. When the SCRNSAVE verb is executed and the destination character variable is too small, the OVER flag is set. Unfortunately, most programs ignore that flag. The error doesn't appear until the attempt to refresh the screen is done with SCRNREST.

    The SCRNSIZE verb was added to provide the programmer with a way to dynamically figure out how large the variable needs to be. Here is some example code:

    CWORK CHAR @
    NWORK INT 6
          SCRNSIZE NWORK
          MAKEVAR ("C" + SQUEEZE CHAR NWORK) TO CWORK
          SCRNSAVE CWORK
    


    Question:

    How do you pass parameters from the command line into a DB/C program?

    Answer:

    Use the CLOCK CMDLINE verb. This provides the entire command line. Your program must parse the parameters out of this line.


    Question:

    What is the use of the ISNULL operator?

    Answer:

    The ISNULL operator is used to test the null state of character and numeric variables. This new variable state was added for support of SQL. SQL character and numeric values can have the null value. Thus when reading data from an SQL database, the DB/C variables are set to the null state if the source value is null. Likewise, when writing to an SQL database, if the source DB/C variable is null, then the value stored in the database is null.

    Note that the null state is different from the DB/C character variable value of zero length (the formpointer is zero) and the DB/C numeric variable value 0.

    You can change the state of a DB/C variable to the null state like this:

    DIM1    CHAR 1
            SETNULL DIM1
    DIM1 is now in the null state

    You change a variable to the non-null state by modifying it in any way, such as with MOVE or CLEAR:

         CLEAR DIM1

    DIM1 is now in the non-null state

    After reading from an SQL table, you can ascertain if a variable is in the null state like this:

         IF (ISNULL DIM1)
              DISPLAY "DIM1 is in the null state"
         ENDIF

    There is no corresponding verb to accomplish the ISNULL test.


    Question:

    What is the purpose of disable and enable statements?

    Answer:

    They provide a way to guarantee that a section of code will complete execution without a trap key or trap timeout interrupting it.

    In GUI programs, they provide an interlock between the user interface thread and the DB/C execution thread so that you can, for example, disallow a change to the state of a control without having a small window of time when the control is in the wrong state.


    Question:

    How can I convert DB/C programs to use SQL instead of DB/C files? What problems might I encounter?

    Answer:

    DB/C DX supports SQL with the SQLEXEC, SQLMSG and SQLCODE statements via dynamic SQL. The eventual interface to the SQL database engine is done using ODBC, JDBC or a proprietary interface in UNIX. Technical details about how SQLEXEC works can be found in the DB/C Programmer's Reference manuals, all well as in the June 1993 and the October 1994 DB/C Newsletters. Old newsletters can be found at the Past Issues of the Newsletter link on the DB/C Newsletter page at www.dbcsoftware.com.

    From experience, we would like to warn you that there are some major problems you will run into if you attempt a conversion to SQL. First, the conversion itself is quite complicated. There are significant differences between the two file systems. Some differences may actually cause you to remove features and functionality from your DB/C programs. Because of the way SQL works, you can't just replace each READ/WRITE statement with one SQL statement. Major restructuring of your program is typically required.

    More importantly, performance may also be a problem. At best, even with restructuring of your programs, expect to run 3 or more times slower when using SQL compared to the DB/C file system on the same hardware.


    Question:

    I'm writing a DB/C GUI application. I've encountered a problem trying to test for 'control has changed' on PANELs and DIALOGs. I've used various methods including QUERY after focus change, but I'm still having problems. What should I do?

    Answer:

    Use ITEM messages. To receive ITEM messages, execute this statement

            CHANGE resource, "ITEMON"

    before you show the dialog or panel resource. For text controls, you will receive an ITEM message with the new value of the control after each keystroke is pressed. This message will contain the complete, current text in the control. For other controls, you will receive an ITEM message whenever the control changes, whether by keystroke or mouse click.


    Question:

    We have a problem with the syntax of SQLEXEC when data contains a string of characters like "ABC:152". This causes the SQL interface of DB/C to attempt to replace ":152" with the value of the 152nd parameter in the SQL list. How can we avoid this problem?

    Answer:

    The SQL interface of DB/C DX uses the back slash character ("\") as the forcing character. This requires you to parse the data and replace all colons (":") and backslashes ("\") with two character sequences of "\:" and "\\" respectively.


    Question:

    With the SQL interface of DB/C DX (SQLEXEC), can I make two concurrent connections to different SQL databases?

    Answer:

    Yes, this feature is new in DB/C DX 11.


    DB/C DX Questions


    Question:

    When I launch the version 13.1 DX runtime on some Windows machines, I get an error message, 'A required .DLL file, ODBC32.DLL, was not found'. Why do I get this and what can I do?

    Answer:

    Prior to DX version 13.1 we encapsulated odbc functionality in a separate file, dbcsql.dll. This file was used only if an SQL verb was executed. As of version 13.1 this separate file has been eliminated and its functions are linked into the DX runtime. As a consequence, Windows needs to load odbc32.dll whenever DX is started. Windows NT 4.0 SP3 and newer will already have this file. For older systems you can get this file from the Microsoft web site.

    There are three ways to solve this:

    You can install MDAC (Microsoft Data Access Components) on each machine that has this problem. Browse to http://msdn.microsoft.com/data/downloads, click on 'Product and Update Downloads', then click on 'MDAC Downloads'. Download and install the latest version of MDAC.

    If you have a copy of odbc32.dll from a newer version of Windows, copy it to each problem machine into a directory that Windows searches for DLLs. This is typically /windows/system32.

    You could make odbc32.dll visible to the clients by placing it on a server and adding an entry to the PATH variable on each machine..


    Question:

    How do we create customized DB/C DX configuration file for each user? For ease of administration, we prefer to use a single DBCDX.CFG file that is shared by all users. In DB/C 9.1, we made the DBC_PORT and DBCVOL_W environment variables be different for each user. How do we accomplish the same thing in DB/C DX?

    Answer:

    The most common method for dealing with this issue is to create a start-up script (.bat or .cmd file in Win32) that appends the dynamic DX properties (like dbcdx.file.vol.W and dbcdx.clock.port) to the static DBCDX.CFG file.

    If each user has a unique work directory that is the current directory, the resulting file would be copied into the work directory with the name DBCDX.CFG and the DB/C runtime would be started with that directory as the current directory.

    It is slightly more difficult if the conditions are different. In this case, the resulting file would be given a temporary file name and then the DB/C runtime would be started with the -cfg=<filename> parameter.

    Another method for dealing with this is to just run CVTENV in the script immediately before starting the DB/C runtime.


    Question:

    Why do we get random data corruptions (index and/or data files), spurious runtime errors including I 1751, I 1753 and R 301 in DB/C DX? The problems occur on local area networks with one or more Windows 95/98 and ME computers.

    Answer:

    Sometime after the initial release of Windows 95, Microsoft started shipping versions of the network client software (redirectors) for both Netware and Microsoft networks that included local (on the client) read/write file caching. Performance improved, sometimes dramatically, but unfortunately DB/C and many other database applications failed miserably.

    Microsoft acknowledged that they created the problem. The solutions are varied, depending on the environment.

    For problems with files on Novell Netware servers, the solution is simple - use the Novell client software for Netware instead of the Microsoft client software for Netware. You can get this software (Client v3.01 for Windows 95/98) from the Novell web site. When you install this software, the Microsoft Netware client software is automatically uninstalled. After installation, be sure to set the following properties in the Control Panel: Properties: Advanced Settings:

    Cached Writes OFF
    File Cache Level 0
    True Commit ON

    For problems with NT server networks, changes need to be made at the server and possibly to the client.

    For Windows peer-to-peer networks, the solution is unclear. In Windows 95, there are one or more .DLL files that may need to be replaced with later versions. Microsoft states that the peer-to-peer problems are fixed in Windows 98.

    Here are three web links that will get you started:

    http://support.microsoft.com/support/kb/articles/Q300/2/16.ASP
    http://support.microsoft.com/support/kb/articles/q148/3/67.asp
    http://support.microsoft.com/support/kb/articles/q163/4/01.asp
    http://support.microsoft.com/support/kb/articles/q126/0/26.asp


    Question:

    Why can't I display a character in the lower right corner of the screen when using DB/C in UNIX?

    Answer:

    This problem occurs when using dumb terminals and the termdef capability. See the DB/C DX Programmer's Reference documentation for tdcmp for a description of termdef. Many dumb terminals roll up one line when a character is displayed in the lower right corner character position. Therefore, by default, DB/C suppresses display of that character. In the termdef file, if you specify the no_roll flag function, the character will be displayed. If your terminal can be switched between roll and no-roll modes with an escape sequence, you should specify the enable_roll and disable_roll terminal control string functions.


    Question:

    Why can't I gray out tabs in a GUI panel or dialog?

    Answer:

    Microsoft does not provide that capability in the Win32 API.


    Question:

    We have some programs for which the program source is missing. Is there a de-compiler tool available to recreate the source for these programs from their .DBC files?

    Answer:

    There is no DB/C decompiler tool that we are aware of. The format of the .DBC file is not publicly documented.


    Question:

    We occasionally get I 602 errors running on Windows NT workstations. The occurrences are seemingly random. What is the cause?

    Answer:

    When any Microsoft Office application is installed, a program called FINDFAST.EXE is installed and is put into the StartUp directory. This program opens all files on local disks that end with certain extensions, including the .TXT extension. The purpose of this is make Office applications open documents, etc. faster. Unfortunately, this causes an I 602 when a DB/C program attempts to open a file that FINDFAST already has open. The solution is to remove FINDFAST.EXE from the StartUp directory.


    Question:

    The performance of DB/C DX for Windows is fine on our 10Mb Ethernet, but over a 64Kb leased line being used as an extension to our LAN, performance is acceptable for one user, but degrades quickly with additional users. What can we do?

    Answer:

    Generally, the Win32 version of DB/C DX, when running in a Wide Area Network (WAN), is somewhat slow. The reason for this is that when an indexed read or write occurs, all index blocks that are affected move between the client machine (running DB/C) and the file server. This problem can be alleviated somewhat by adding bandwidth - generally 32K to 64K per user just for minimally adequate performance.

    A better solution is to use the Smart Client feature of DB/C DX.


    Questions:

    In UNIX, if I define dbcdx.memalloc=6000 and then start the DB/C DX runtime, does it allocate all of the 6MB immediately? Is this memory allocated by the DB/C runtime swappable?

    Answer:

    Yes, the memory is allocated immediately. The memory is swappable.


    Question:

    We use the EDIT utility to edit some large data files. Unfortunately, it only seems to be able to load about 10,000 70 character records. Is there anything we can do?

    Answer:

    Use the -A option on the EDIT command line to enlarge the in-memory work area of EDIT. The size of files that may edited with EDIT is limited by size of the in-memory work area buffer. Note that in both Win32 and UNIX, the value of -A is limited only by system swap space, not by physical memory. Thus it is possible to edit very large files with EDIT.


    Question:

    Our package software is sold on a per user basis. Can the DB/C DX user counting mechanism be changed to increment by one user instead of 5, 10 or 20 users as it now works?

    Answer:

    The 18 digit key used to control user count in DB/C DX software products is an encryption of several values including license number, user count and operating system. Significant reprogramming would be required to change this functionality. If your software has a high per seat value, we recommend using a hardware key (also known as a dongle) to control access to your software.


    DB/C FS Questions


    Question:

    When using the Microsoft ADO interface to access files managed by DB/C FS 2, it seems that the column description from the DBD file becomes the column name. How can we get around this?

    Answer:

    ADO uses ODBC to access information in ODBC databases such as DB/C FS. The ODBC API has grown over the years and is now quite complicated. Many functions were added in ODBC 2.x and ODBC 3.x. Some of the capabilities of the newer ODBC functions overlap the capabilities of older functions. The DB/C FS ODBC driver that comes with DB/C FS 2.2 is ODBC 3.x compliant.

    There are several ODBC functions that client software can call to retrieve the name, label, remarks and other information about a column. We have tried to adhere to the Microsoft documentation for those ODBC functions that DB/C FS uses. Unfortunately, the documentation having to do with column information isn't very clear. It appears that ADO uses certain ODBC functions in a way that causes the column description to become the column name.

    This problem is resolved in DB/C FS 3.


    Question:

    Why can't I start the NT version of DB/C FS from the command line when it's installed as an NT service and the service is stopped?

    Answer:

    This is a limitation of DB/C FS. We will look into making this possible in a future release of DB/C FS. For now, if you need to run it from the command line (such as for for debugging), uninstall DB/C FS as a service first (run 'dbcfs -u') and then start it manually.


    Question:

    When attempting to access a DB/C FS database from certain query tools like Crystal Reports and Microsoft Access, this error message occurs: [SWC][FS2 ODBC Driver]NAME is invalid

    Answer:

    As defined by Microsoft, the ODBC interface does not specifically require that the client program actually login to the database that will be accessed. Some client software programs require the user to provide a login name and password, whereas others don't. This is a security risk. To alleviate the problem, when no user name is provided by the client software, the DB/C FS ODBC driver will login to the DB/C FS server with the user name 'DEFAULTUSER' and the password 'PASSWORD' (without the quote characters). Thus, to allow Crystal Reports, Microsoft Access and other client programs to login, add a name and password entry to the dbcfspwd.cfg file for user 'DEFAULTUSER' with password 'PASSWORD'. Be sure to specify the access= parameter for 'DEFAULTUSER'.


    Question:

    When using DB/C FS, why does my Microsoft Access query take so long?

    Answer:

    Microsoft Access sends database queries to the database front end that Microsoft calls the 'Jet Engine'. This software converts even the simplest query into a template-driven SQL SELECT statement that is quite complicated. Specifically, 'Jet' generally creates a WHERE clause that contains an expression with 10 or more OR operators. This statement is sent from 'Jet' to DB/C FS via ODBC. DB/C FS attempts to optimize each SELECT statement by using the appropriate index to satisfy WHERE and ORDER BY clauses, but when the statement is complex, DB/C FS falls back to reading the entire file sequentially, selecting records that match the WHERE clause, and then sorting the result to match the ORDER BY clause.

    Fortunately, Access provides a way to bypass the 'Jet Engine'. This feature is called the 'Pass Through Query'. With this feature you specify the SQL SELECT statement manually. In general, SELECT statements with a few joined tables and simple WHERE and ORDER BY clauses will be optimized by DB/C FS. For large text files, the performance difference between an optimized and a non-optimized SELECT can be quite large. The same record retrieval that takes a couple of seconds with 'Pass Through' can take many minutes with 'Jet'.


    Question:

    I would like to update DB/C data files concurrently with an existing DB/C application and with another application that uses SQL. DB/C FS seems to allow this, but data integrity must be maintained. How does the locking mechanism of DB/C FS work in conjunction with FILEPI and record locking in DB/C DX?

    Answer:

    When a program executes an SQL SELECT FOR UPDATE, DB/C FS creates a record lock on each record as it is fetched. The intent is for that record lock to work in conjunction with DB/C record locking (but not FILEPI) so that data integrity can be maintained. However, to work correctly, DB/C FS must use the same file offsets for record locking that DB/C DX is using. As long as DX and FS are running on the same operating system, you shouldn't need to do anything special - all will work. If you are using SAMBA or something like that to allow DB/C Windows applications to access files on the UNIX disk, then the offsets probably don't match and the record locking won't work. A good discussion of this is found in the February 2000 DB/C Newsletter.

    Thus, FILEPI is useless in this situation. Your DB/C programs need to be using record locking to work effectively in a DB/C FS environment with SQL applications where both are concurrently updating records.