Running on Local Area Networks Overview The Superbase version 2.0 Install program allows you to decide the type of locking to install for Superbase (single user, LAN, or distributed LAN locking) and for the LAN versions only, the maximum number of users to set Superbase up for. This information is contained in the SBINFO.DLL file. The only differences in the three versions of Superbase are the SBLOCK.DLL and different settings in the SBINFO.DLL. Otherwise, the rest of the files are identical, thus achieving complete application compatibility between the 3 different Superbase installed versions. This installation schema also marks the beginning of the Superbase compliance to the SPC LAN Policy of a user definable LAN version from a single product. There are no 5 User LAN Extension products in the Superbase family of products, beginning with Superbase. Single user locking The single user version of Superbase differs from the other two LAN versions in the SBLOCK.DLL functionality. This file actually provides a Memory Model Locking scheme to Superbase, simulating the file and record locking provided by the other versions. This version does not require the Superbase Network Control File (SUPERBAS.NET), nor the Superbase lock files (*.SB!). In fact, if it finds a Superbase lock file on a Network drive when attempting to open a file, it displays an error, number 178, "File only accessible from the LAN version." This option is selectable from the Superbase Install program and is the default installation type in the dialog. Selecting this type does not result in the subsequent number of users dialog presented after selecting either of the LAN version installation type options. The SBLOCK.DLL file is recognizable by the file size of approximately 15,056 bytes. LAN locking The LAN version of Superbase differs from the Single User and Distributed LAN version in the SBLOCK.DLL functionality. This file provides a Single Network Control File (NCF) Locking scheme, controlling the file and record locking and limiting the file access to only the Superbase lock files owned / created by this One NCF. This version requires a Single Superbase Network Control File (SUPERBAS.NET). Each file accessed by this version of Superbase has a Superbase lock file (*.SB!) created. Each of these Lock files is owned by the active NCF. In fact, if Superbase finds a Superbase lock file not owned by the current NCF when attempting to open a file, it displays an error, number 173, "Invalid Lock File." This option is selectable from the Superbase Install program and is the second installation type in the dialog. Selecting this type results in the subsequent number of users dialog. The LAN Locking uses the minimum system resources, File handles and Lock handles, when compared to the Distributed LAN version. It also has the benefit of allowing the total number of concurrent Users to be tracked. The SBLOCK.DLL file is recognizable by the file size of approximately 31,696 bytes. Distributed LAN locking The Distributed LAN version of Superbase differs from the Single User and LAN version in the SBLOCK.DLL functionality. This file provides a Directory Network Control File (NCF) Locking scheme, that is, One NCF per Directory, controlling the file and record locking and limiting the file access to only the Superbase lock files owned/created by this One NCF. This version differs from the LAN version in that there can be multiple active NCF files. This version does require a Single Superbase Network Control File (SUPERBAS.NET) per directory. Each file accessed by this version of Superbase will have a Superbase lock file (*.SB!) created. Each of these Lock files is owned by the active NCF. In fact, if Superbase finds a Superbase lock file not owned by the current directory's NCF when attempting to open a file, it displays an error, number 173, "Invalid Lock File." This option is selectable from the Superbase Install program and is the third or last installation type in the dialog. Selecting this type results in the subsequent number of users dialog. The Distributed LAN Locking uses more system resources, File handles and Lock handles, when compared to the LAN version. It does not allow the total number of concurrent Users to be tracked, as to do so requires that the total users be added from each active Network Control file. It does have the benefit of not requiring all users to access a single file, Network drive, LAN server as the LAN version does. The SBLOCK.DLL file is recognizable by the file size of approximately 31,984 bytes. System requirements Superbase requires complete DOS version 3.3 compatibility in the LAN environment. The File and Record Locking is controlled via the Network Control File/Lock File functionality. The only DOS function required for locking is the Interrupt 21 Function 5C facility provided in DOS version 3.3. This locking function can be described as Locking a Region of a File, as opposed to locking of the entire file. Superbase relies on this locking function to enable the smooth recovery of the workstation, server, or other system failures. Otherwise it handles the file access control and record locking internally, which gives us the LAN Operating system portability that we have enjoyed since version 1.3x. One benefit of this schema is the ability for Superbase to happily exist on almost any DOS version 3.3 compatible LAN and even some that simulate the DOS version 3.3 compatibility on other non PC platforms like the Sun File Server with NFS. Superbase, being a Windows application program, is also dependent on Windows Network compatibility issues. Such as the need for the Read Only bit for sharable Executable files on the Network drive. Network locking file The Superbase Network locking file, SBLOCK.DLL, is a Dynamic Link Library file used to control File and Record Locking. There are three different versions of this file, described previously. If this file is replaced by one of the other versions by any other method other that reinstalling Superbase, when Superbase loads, the error, number 169 - Invalid Superbase Library, occurs. The LAN version of this file allows only one NCF, while the Distributed LAN version allows multiple NCF files, one per directory. Network control file The Network Control File controls the number of users on the system and contains specific information about the users and database files. The user information contained in the NCF includes database file access modes for each user and file. This file also tracks the number of concurrent users running Superbase. The LAN version can have only one NCF, while the Distributed LAN version has multiple NCF files, one per directory. A better description of the Distributed LAN version of the NCF would be a Directory Control File (DCF). The Distributed LAN version cannot properly track the concurrent users as there is no NCF controlling the DCF files in each directory. Lock file This Superbase Lock file uses the parent file's root name and the SB! extension. It is owned by the active NCF when it is created, that is it contains a unique identifier to the NCF file. This file controls record access to the parent database file, or concurrent access to sequential files, like the SBP, SBQ, SBT, TXT, SBU, SBB, SBK, etc. When the Lock file is used with database files, it tracks the record locks and user links to the NCF that established the locks. This file remains after the user access is ended and helps control Single user access to Network data by its very existence. When the Lock file is used with the sequential files, it controls the edit access to the file. This type of lock file is temporary and is removed when the edit session is complete. When a database file and a sequential file share the same root name, Superbase creates one Lock file for both. This file has the primary roll of the database Lock file, with a secondary role of the sequential file access control. It is permanent like the database Lock file. The actual low level locking done with both versions of the Lock file is a technique to lock a region of the file that does not actually exist. This technique allows the clearing of the workstation off the Network by LAN Administration software or the act of the Workstation Logging back onto the Network, to automatically clear the record locks left active by a workstation crashing. Optimizing performance Superbase The following optimization techniques are viable for all three versions of Superbase. They are not dependent on the Single User, LAN or Distributed LAN versions. Files, Buffers, and Share The CONFIG.SYS and Superbase file/buffer settings can be adjusted for optimum performance. This adjustment requires consideration of the application being optimized. Additional information can be found in technote #4047, Files and Buffers. Windows The Windows manual and supplied background documentation can provide the information necessary for optimization of the Windows environment. The Hardware suggestions for optimization are: A fast hard drive, as database products are traditionally disk intensive. The more memory the greater the flexibility in configuration. A fast video board can speed even the slowest 386SX with 2 MB of memory to a near 386DX/33mhz performance level. Defragmenting the hard drive can provide a large speed benefit. Workstation Installation of Windows and all of the software locally greatly affects Network performance as this eliminates much of the LAN communications traffic. Shared data files have to be on the LAN, however, temporary tables and static lookup files can also contribute to the overall performance increase if these are installed locally. Network Providing the fastest LAN communications hardware to a workstation can help eliminate the communications bottleneck, which can slow down the fastest software. A case in point is the replacement of the 3Com 3C505 with the 3C507 eithernet cards and moving from the coax cabling to the twisted pair/concentrators/fiberoptics interconnecting network. Minimizing the network traffic by providing large enough local hard drives to hold the workstation software. Installing fast LAN software like Novell Netware and providing the quality server hardware with sufficient memory to cache the server drives has greatly increased the speed of the network. Interactive locking The interactive use of Superbase is similar to that of version 1.3x, except when dealing with locking a form with detail blocks. When dealing with a form with detail blocks, the locking rules are: The user locks records from the point in which they select to the top of the relation. Records linked with a one to one relation in the selected detail block row arel not locked unless they have fields that are placed in the detail block row. Records linked to the master file with a one to one relation will not be locked unless they have fields that are placed on the form. For example, let's say that we have a one to one relation with the master file and we are assigning the fields from the related file (lookup file) to fields in the master file, this lookup file's record would not be locked because there are no fields from this file on the form. Let's use the above scenario but the primary file is a detail block file, again because we are not placing a field from the lookup file in the detail block row, the lookup file's record will not be locked. Let's use a complex example of a master file linked to a primary detail block, a secondary detail block linked to the primary detail block, a third detail block linked to the secondary detail block and finally a fourth detail block linked to the third detail block. This could be termed a one to many to many to many relation, whew, lots of manys. Now let's say that the user selected a row in the third detail block. The Master file's record, the linked records in the secondary, and primary detail blocks, plus the selected record in the third detail block would be locked. This is shown in the drawing above by the shading. However the other records in the primary, secondary, and third detail block that were not selected and all records in the fourth detail block would remain unlocked. This is because the interactive locking is up the relation chain from the selected record and not down the chain. Let's use a one to one relation to the master file and the related lookup file's field is placed on the form. This lookup file's record would be locked. Last in our examples, let's use a one to one relation to a record in a detail block row and the related lookup file's field is placed on the form. This lookup file's record would be locked. When placing read only fields on a form from a lookup file, generally the record would not need to be locked. Superbase still locks this record unless the lookup file is opened in a read only mode (SHARE,4 or SHARE,6). Program controlled locking When selecting records under program control (non-native mode), the SELECT statement must include the LOCK parameter, as in SELECT FORM CURRENT LOCK. For One to One links (non-detail block), this results in all records being locked. For One to Many links (Master to Detail Block), this results in only the records at the Master file level (outside of the detail block) being locked. Superbase version 2 still uses the interactive facilities for locking of the detail block records. These interactive facilities require a user selection of a detail block row to perform the locking. If a programmer desires to lock a detail block row, and assign values to the detail block row's record without user intervention, then a file level lock must be established before the field assignment. Otherwise the 'record not locked' error can occur. The following is an example of this technique created for the SAMPLES\STOCK\ORDER.SBV form: SUB UpdateRow() REM select the detail block row SELECT FORM DROW "OrderDetails",1 REM make the detail block file current FILE "items" REM make the same record current that was selected in the REM detail block, at the file level SET INDEX ALL REM Lock the record SELECT CURRENT LOCK REM make the assignment to a field OrderQuantity.Items = OrderQuantity.Items + 1 REM store the changed record STORE REM make the form's master file current FILE "order" REM force the record data re-read from the files SELECT FORM CURRENT REM Display the changed data in the form FORM END SUB Program: Superbase Versions: 2.0 Date: June 24, 1993 D Date: