(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Inconsistencies in LockPhysicalRecordSet()
DOCUMENT ID#:FYI.A.2845
DATE:02DEC92
PRODUCT:NetWare C Interface DOS
PRODUCT VERSION:v1.2
SUPERSEDES:NA
SYMPTOM
Cannot lock the records with shareable read-only locks with the LockPhysicalRecordSet() function.
ISSUE/PROBLEM
Calling LockPhysicalRecordSet() with lockDirective parameter of 1 (shareable read-only) actually locks the record exclusively. This function locks records exclusively for a lockDirective parameter of 1 or 0.
SOLUTION
NA
FYI:Multiple NetWare Logins under Windows 3.1
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Multiple NetWare Logins under Windows 3.1
DOCUMENT ID#:FYI.A.4502
DATE:02DEC92
PRODUCT:NetWare C for Windows
PRODUCT VERSION:v1.3
SUPERSEDES:NA
SYMPTOM
NA
ISSUE/PROBLEM
Is it possible to log in and out of a NetWare server from a Windows 3.1 DOS box?
SOLUTION
To log in and out of a NetWare server multiple times from a DOS window, several conditions must be satisfied:
1.The shell (IPX/ODI and NETX) must be loaded before starting Windows.
2.VIPX.386 should be version 1.13 or later.
3.Set NWShareHandles = TRUE to share drive mappings among DOS sessions. This parameter is in the [NetWare] section of the Windows SYSTEM.INI file.
4.A path must be maintained to the \LOGIN subdirectory of a NetWare server.
FYI:IPXODI 2.0 Diagnostic Call Bug
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:IPXODI 2.0 Diagnostic Call Bug
DOCUMENT ID#:FYI.A.6001
DATE:25NOV92
PRODUCT:NetWare C Interface DOS
PRODUCT VERSION:v1.20
SUPERSEDES:NA
SYMPTOM
Diagnostic calls return incorrect information.
ISSUE/PROBLEM
When running IPXODI version 2.0, GetServerAddressTable() and GetServerNameTable() return empty information buffers. The exact same calls function properly under IPXODI version 1.2.
SOLUTION
Use IPXODI version 1.2 if you need to use these calls.
FYI:Must ScanSalvagableFiles before Purging
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Must ScanSalvagableFiles before Purging
DOCUMENT ID#:FYI.A.4601
DATE:23NOV92
PRODUCT:Network C Interface for DOS
PRODUCT VERSION:v1.20
SUPERSEDES:NA
SYMPTOM
Setting the entryID parameter in PurgeSalvagableFile to -1 as suggested in the documentation will always cause it to fail.
ISSUE/PROBLEM
The documentation states that an initial search can be performed by setting entryID to -1. However, this is not correct. PurgeSalvagableFile() cannot scan for files to be purged.
SOLUTION
You must call ScanSalvagableFiles() to get a valid entryID value before calling PurgeSalvagableFile(). That entryID will allow PurgeSalvagableFile() to identify the directory entry to be purged.
FYI:Mismatched Error Codes in Message Services
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Mismatched Error Codes in Message Services
DOCUMENT ID#:FYI.A.4602
DATE:23NOV92
PRODUCT:Network C Interface for DOS
PRODUCT VERSION:v1.20
SUPERSEDES:NA
SYMPTOM
Decimal error code values do not match hex error code values in the documentation for several Message Services functions.
ISSUE/PROBLEM
The documentation in the NetWare C Interface for DOS manual for BroadcastToConsole(), CloseMessagePipe(), and GetBroadcastMessage() all show an error code "253 (0xFC) MESSAGE_QUEUE_FULL". Decimal 253 does not equal hex FC.
SOLUTION
The hex value is correct. The decimal values should be 252.
FYI:Error in CONVHNDL.C
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Error in CONVHNDL.C
DOCUMENT ID#:FYI.A.1527
DATE:20NOV92
PRODUCT:NetWare C Interface for DOS
PRODUCT VERSION:v1.2
SUPERSEDES:NA
SYMPTOM
NA
ISSUE/PROBLEM
CONVHNDL.C will not return information correctly about the root directory of any volume. If you need to pass the root directory as the path for any of the following calls, a status 156 (0x9C), Invalid Path, will be returned. This function is not called directly by the user application, but is called by the following functions:
API calls : GetEffectiveRights
PurgeSalvagableFile
RecoverSalvagableFile
SetTrustee
ScanDirEntry
ScanEntryForTrustees
ScanFileEntry
ScanFilePhysical
SOLUTION
The problem is located on line 120 of CONVHNDL.C. Please make the following change to the source code to fix the problem. Recompile the source module and replace it in the NIT library.
Line 120 : strcpy( newDirPath, '\0' );
New Line 120 : strcpy( newDirPath, "\0" );
FYI:Unique Passwords
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Unique Passwords
DOCUMENT ID#:FYI.A.3858
DATE:18NOV92
PRODUCT:NetWare
PRODUCT VERSION:v3.11
SUPERSEDES:NA
SYMPTOM
NA
ISSUE/PROBLEM
If the Unique Passwords requirement is enabled through SYSCON, and a password is changed to one of the old passwords through SYSCON, the password is accepted and no error messages are given.
SOLUTION
Whenever a password is changed through SYSCON, the password expiration date defaults to January 1, 1985. If this expiration date is not changed to a date later than the current date, SYSCON will accept any passwords that were used previously even though the Unique Passwords restriction is on. Therefore, make sure that the password expiration date is valid.
FYI:Calling _msize() with Protected Memory
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Calling _msize() with Protected Memory
DOCUMENT ID#:FYI.A.1528
DATE:27MAR92
PRODUCT:Network C for NLMs
PRODUCT VERSION:v2.0b
SUPERSEDES:NA
SYMPTOM
NA
ISSUE/PROBLEM
If a call is made to _msize() for a piece of protected memory, the size returned for the memory is incorrect. This is apparent when running under PROTECT.NLM, if an application calls realloc(), that calls _msize, the size of memory returned is an unpredictable number. This incorrect size may cause memory corruption, etc.
SOLUTION
NA
FYI:GetSpecificCaptureFlags() Always Returns Zero in AL
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:GetSpecificCaptureFlags() Always Returns Zero in AL
DOCUMENT ID#:FYI.A.2846
DATE:11NOV92
PRODUCT:NetWare System Calls for DOS
PRODUCT VERSION:v1.0
SUPERSEDES:NA
SYMPTOM
GetSpecificCaptureFlags() always returns a status zero.
ISSUE/PROBLEM
GetSpecificCaptureFlags() always returns a status zero in AL. However, AH returns a zero if the reply buffer is filled, and non-zero if the reply buffer is not filled because IPX or NETX was not loaded (DOS).
SOLUTION
The documentation is incorrect. Use AH as the completion code instead of AL.
FYI:Get Connection Information Needs 64 Byte Reply Buffer
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Get Connection Information Needs 64 Byte Reply Buffer
DOCUMENT ID#:FYI.A.4806
DATE:11NOV92
PRODUCT:NetWare System Calls
PRODUCT VERSION:v1.00
SUPERSEDES:NA
SYMPTOM
The workstation loses connection with the server or function call returns invalid data.
ISSUE/PROBLEM
GetConnectionInformation() requires a 64 byte reply buffer to return information from the call instead of a 63 byte reply buffer.
SOLUTION
Resize the reply buffer in the application to 64 bytes.
FYI:Documentation Error for SetDefaultCaptureFlags()
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Documentation Error for SetDefaultCaptureFlags()
DOCUMENT ID#:FYI.A.2847
DATE:11NOV92
PRODUCT:NetWare C Interface DOS
PRODUCT VERSION:v1.2
SUPERSEDES:NA
SYMPTOM
SET_CAPTURE_FLAGS structure not defined properly.
ISSUE/PROBLEM
In Volume II of the NetWare C Interface for DOS manual (July 1990 edition) on page 15-42, the last field in SET_CAPTURE_FLAGS structure is defined as "BYTE PAD02" instead of "BYTE PAD[21]". Also, the flushCaptureOnDeviceClose and flushCaptureTimeoutCount fields are in reverse order.
SOLUTION
The NWPRINT.H file has the fields in the structure aligned properly.
FYI:Inconsistencies in the Header Files
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Inconsistencies in the Header Files
DOCUMENT ID#:FYI.A.2848
DATE:11NOV92
PRODUCT:NetWare C Interface DOS
PRODUCT VERSION:v1.2
SUPERSEDES:NA
SYMPTOM
NA
ISSUE/PROBLEM
In DIAG.H the linkAddress and ESRAddress fields in the ECB structure are defined as an array of WORD where as in NXT.H they are defined as far pointers. This will cause some problems if you have an ESR defined in your application and the include file DIAG.H exists before NXT.H, because of the inconsistent ECB structure definitions.
SOLUTION
Do not include DIAG.H before NXT.H if an application is making IPX calls, or modify linkAddress and ESRAddress fields in DIAG.H to the following:
void far *linkAddress;
void (far *) ();
Also, use this method if not calling a ESR routine from an application; otherwise, the appropriate ESRAddress is passed in.
FYI:Incorrect Temporary Drive Letter
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Incorrect Temporary Drive Letter
DOCUMENT ID#:FYI.A.6002
DATE:10NOV92
PRODUCT:NetWare C Interface DOS
PRODUCT VERSION:v1.20
SUPERSEDES:NA
SYMPTOM
NA
ISSUE/PROBLEM
In the NetWare C Interface for DOS volume I page 8-24, the documentation incorrectly refers to the last temporary drive letter as an apostrophe ('). The correct last temporary drive letter should be a grave accent (`).
SOLUTION
NA
FYI:Temporary Directory Handle
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Temporary Directory Handle
DOCUMENT ID#:FYI.A.6003
DATE:10NOV92
PRODUCT:NetWare C Interface DOS
PRODUCT VERSION:v1.20
SUPERSEDES:NA
SYMPTOM
API calls function incorrectly or not at all.
ISSUE/PROBLEM
If temporary directory handle "\" (27) is passed to GetDirectoryPath the correct path is returned.
However, temporary directory handle "\" (27) is misread by the following API calls as pointing to the root directory of whatever volume it is mapped to, irregardless of where in the directory structure it should actually point:
GetEffectiveRights
SetTrustee
ScanDirEntry
ScanEntryForTrustees
ScanFileEntry
ScanFilePhysical
SOLUTION
Do not use directory handle "\" (27).
FYI:ioctl() Prototype is Missing from CLIB
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:ioctl() Prototype is Missing from CLIB
DOCUMENT ID#:FYI.A.3859
DATE:10NOV92
PRODUCT:Network C for NLMs
PRODUCT VERSION:SDK 2.0(E)
SUPERSEDES:NA
SYMPTOM
NA
ISSUE/PROBLEM
The ioctl() prototype is missing from the header files of CLIB.NLM v.3.11 b. This generates a warning message from the compiler.
SOLUTION
This is only a warning message so it can be ignored for right now. It will be fixed in a later release. Previously the prototype of ioctl() was found in the STROPTS.H file.
FYI:Limit on FILE HANDLES and DOS FILES
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Limit on FILE HANDLES and DOS FILES
DOCUMENT ID#:FYI.A.4603
DATE:10NOV92
PRODUCT:NetWare Shell
PRODUCT VERSION:v3.26
SUPERSEDES:NA
SYMPTOM
System runs out of file handles for network files despite a high FILE HANDLES setting in SHELL.CFG.
ISSUE/PROBLEM
A user found that despite setting FILES=255 in CONFIG.SYS and FILE HANDLES=255 in SHELL.CFG, an application was unable to open more than about 45 files before running out of handles.
SOLUTION
The total number of DOS FILES and NetWare FILE HANDLES must not add up to more than 254. Setting DOS FILES=255 overrides any NetWare FILE HANDLES setting by taking up all of the available handle slots.
If a large number of handles are required, start by setting FILES=127 and FILE HANDLES=127 then adjust the balance as necessary.
FYI:Invalid Date/Time Format Returned by readdir()
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Invalid Date/Time Format Returned by readdir()
DOCUMENT ID#:FYI.A.3388
DATE:05NOV92
PRODUCT:Network C for NLMs
PRODUCT VERSION:v20d
SUPERSEDES:NA
SYMPTOM
Date/Time fields set to incorrect values.
ISSUE/PROBLEM
The readdir() API is returning date/time fields in an unusual format. The format is similar to the DOS date/time format, but not identical. Therefore, the SetFileInfo API will set the time and date information incorrectly if the fields are passed directly from readdir. The manual states the dates should be stored in DOS format for SetFileInfo. However, to accomplish this, the dates/times returned from readdir must be modified. The four byte date/time value must have the two words swapped, but the words themselves should not be swapped.
Example:
AA BB CC DD needs to be stored as CC DD AA BB to set the date to the correct value for SetFileInfo.
SOLUTION
Simply using LongSwap will not solve the problem as LongSwap will also swap the values in the words as well. To correct the problem, only swap the location of the two word values.
Example:
This example assumes the receiving fields have been defined as character arrays.
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Unable to Obtain Originating Name Space
DOCUMENT ID#:FYI.A.3389
DATE:05NOV92
PRODUCT:NetWare System Calls
PRODUCT VERSION:v1.20
SUPERSEDES:NA
SYMPTOM
NA
ISSUE/PROBLEM
The ScanDirEntry() and ScanFileEntry() calls do not return the originating/owning name space of a file or directory entry.
SOLUTION
The ObtainFileOrSubdirectoryInformation() 3.x System call using the F2 interface returns this information. Example code is available from Developer Support that demonstrates the use of this call.
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
When a lower case string is passed into the fileServerName parameter of AttachToFileServer(), the API will attach you to the appropriate file server.
At this point, the WHOAMI utility works fine. However, after the LoginToFileServer() is performed, the WHOAMI utility will return an error code. The LOGOUT command will also not recognize the lower case server name.
SOLUTION
Ensure that all object names are upper case when passed as parameters to the API functions. Apparently, NetWare utilities are expecting object names to be in upper case.
FYI:CloseMessagePipe() Does Not Return Correct Status
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:CloseMessagePipe() Does Not Return Correct Status
DOCUMENT ID#:FYI.A.4902
DATE:29OCT92
PRODUCT:NetWare C Interface DOS
PRODUCT VERSION:v1.2
SUPERSEDES:NA
SYMPTOM
The CloseMessagePipe() API does not return the error code 253, MESSAGE_QUEUE_FULL, when the requesting workstation's queue is full.
ISSUE/PROBLEM
When another workstation sends the six messages to the requesting workstation desiring to close its Pipe, the function will close the Pipe and discard all messages. But the function does return the expected error code 253 warning the requesting workstation that its message queue is full.
SOLUTION
Do not expect a MESSAGE_QUEUE_FULL (253) status from the function. A SUCCESSFUL (0) status will be returned instead.
FYI:Creating Btrieve Quick Library for MS Visual Basic for DOS
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Creating Btrieve Quick Library for MS Visual Basic for DOS
DOCUMENT ID#:FYI.A.2119
DATE:02DEC92
PRODUCT:Btrieve for DOS
PRODUCT VERSION:v5.10a
SUPERSEDES:NA
SYMPTOM
NA
ISSUE/PROBLEM
When developing Btrieve applications using the Microsoft Visual Basic for DOS interpreter environment (VBDOS), a Quick Library that includes the required Btrieve interface must be created.
SOLUTION
|--> Name of Quick Library
|
Link /q bc7rbtrv.obj, bc7.qlb, , vbdosqlb.lib;
| |
|--> Btrieve Interface |--> Required Library
To load the Visual Basic for DOS environment to include the newly created Quick Library execute the following command:
VBDOS /L BC7
FYI:RealWorld and BUTIL.EXE
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:RealWorld and BUTIL.EXE
DOCUMENT ID#:FYI.A.1123
DATE:01DEC92
PRODUCT:Btrieve for DOS
PRODUCT VERSION:v5.10
SUPERSEDES:NA
SYMPTOM
NA
ISSUE/PROBLEM
Novell will allow RealWorld to distribute their BUTIL.EXE file to RealWorld users. The following statement will go into RealWorld's newsletter this month.
SOLUTION
BUTIL.EXE and version 6.5
In last month's newsletter, RealWorld Dealers were directed to Novell to obtain the utility BUTIL.EXE to run the RealWorld file utility with Btrieve. By an agreement between RealWorld and Novell, RealWorld will be able to supply this utility with each Btrieve System Manager. Therefore, please call RealWorld instead of Novell to obtain this utility.
Important Note: BUTIL.EXE is called from within RealWorld software and it is supplied only for this function. Neither RealWorld nor Novell will support BUTIL.EXE being executed by itself. Such use can alter, damage, or cause a loss of data.
FYI:GetNextExtended Operation after GetKey
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:GetNextExtended Operation after GetKey
DOCUMENT ID#:FYI.A.1771
DATE:25NOV92
PRODUCT:Btrieve for DOS
PRODUCT VERSION:v5.10a
SUPERSEDES:NA
SYMPTOM
Status 19; garbage in data buffer
ISSUE/PROBLEM
If the GetKey bias (+50) is used when establishing positioning before a GetNextExtended operation, the extended call will not function properly, returning either a status 19 (Unrecoverable Error) or garbage in the data buffer. This problem exists in Btrieve for DOS v5.10a and NetWare Btrieve v5.15.
SOLUTION
Patch #57 will fix the problem with NetWare Btrieve, but there is no fix currently available for Btrieve for DOS. In this case, do not use the GetKey bias before the GetNextExtended; use a GetFirst, GetEqual or some other operation to establish positioning without the +50 bias.
FYI:Btrieve and Cache Memory Errors
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Btrieve and Cache Memory Errors
DOCUMENT ID#:FYI.A.1948
DATE:24NOV92
PRODUCT:NetWare Btrieve NLM
PRODUCT VERSION:v6.00
SUPERSEDES:NA
SYMPTOM
NA
ISSUE/PROBLEM
The following error was returned when NSSTART was executed at the file server:
On a five-user version of NWSQL v3.0, the number of users parameter in NDBSetup had been raised to 250. After this, the above errors were returned; since NWSQL would not load, NDBSetup could not be used to lower the appropriate parameter.
SOLUTION
The problem was eliminated by modifying the BSTART.NCF file and lowering the "s parameter and the "m" parameter on the BTRIEVE.NLM load command; the "m" parameter was exorbitant due to the high "s" parameter; both parameters were reduced to their default values.
FYI:New Status Codes for NetWare SQL v3.0
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:New Status Codes for NetWare SQL v3.0
DOCUMENT ID#:FYI.A.1124
DATE:09NOV92
PRODUCT:NetWare SQL
PRODUCT VERSION:v3.0
SUPERSEDES:NA
SYMPTOM
NA
ISSUE/PROBLEM
Four new status codes have been added to NetWare SQL since the release of version 3.0. These codes are not documented in the NetWare SQL Status Codes and Messages manual (January 1992 edition).
SOLUTION
350Security has not been enabled on this dictionary.
You have attempted to perform an operation that can only be done when security is enabled. Database security is not enabled at this time.
351 A transaction has not been started yet.
You must start a transaction before performing a COMMIT or ROLLBACK operation.
352 Record count must be greater than zero.
The record count for an xFetch call must be at least 1.
886Incorrect Btrieve file version for this operation
Referential integrity constraints can only be defined on Btrieve file versions 6.0 or later. If you wish to add referential integrity to this file, use BREBUILD to convert it to the v6.0 file format.
887(The text for status code 568 really belongs here. Status code 568 is not used. The text message for status 568 follows; the details are in the NetWare SQL Status Codes and Messages manual:) A CREATE TABLE statement cannot reference the same table more than once.
888Primary key is already defined on this table.
A table may contain at most one primary key. You have attempted to define a second primary key on this table.
FYI:Substitution Variable Problem with NetWare SQL Inserts
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Substitution Variable Problem with NetWare SQL Inserts
DOCUMENT ID#:FYI.A.1772
DATE:09NOV92
PRODUCT:NetWare SQL
PRODUCT VERSION:v3.0a
SUPERSEDES:NA
SYMPTOM
Multiple records inserted with the same field value.
ISSUE/PROBLEM
There is a problem with the NetWare SQL NLM v3.0 when inserting records through a substitution variable, if the data being inserted contains the @ character. All subsequent inserts with the same cursor are given the same data for that field.
For example: XQLCompile of "INSERT INTO Patients (ID, First^Name, Last^Name, Address) VALUES (@V1, @V2, @V3, @V4)"
The second insert, and all subsequent inserts based on the same XQLCompile, will result in each record being inserted with the same address as the first record: "100 Main @ 1st"
This problem can be seen through an application making the above calls, or when using the "Load" option of the NetWare SQL Maintenance utility (NSUTIL.EXE and NSUTIL.NLM), since it is making the same calls. With NSUTIL, the problem will occur with all of the file formats: SDF, UNF, DIF or ASC.
This problem is only present with Insert statements using substitutions; update statements with substitutions work properly.
SOLUTION
NetWare SQL is confusing the @ in the data with a substitution variable indicator. The only workaround at this time is to recompile the statement between XQLSubst/XQLExec calls, or append the actual data values into the Insert statement passed in on the XQLCompile instead of using the substitution variables.
FYI:Printing through Xtrieve - Tabloid Setting Correction
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Printing through Xtrieve - Tabloid Setting Correction
DOCUMENT ID#:FYI.A.1125
DATE:06NOV92
PRODUCT:Xtrieve PLUS
PRODUCT VERSION:v4.11
SUPERSEDES:NA
SYMPTOM
NA
ISSUE/PROBLEM
The XTRIEVE.PDB file that shipped with NetWare SQL v3.0 was altered just before the product shipped by mistake. The TABLOID setting was changed from IBM PC Graphics printer to EPSON LQ-1500/2.0.
SOLUTION
To change the TABLOID setting back to the original setting, the printer information needs to be changed as specified in the following steps:
This procedure will change the current setting of EPSON LQ-1500\2.0 to the correct setting of IBM PC Graphics Printer.
FYI:Determining If Data Dictionary Files Are Corrupted
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Determining If Data Dictionary Files Are Corrupted
DOCUMENT ID#:FYI.A.1126
DATE:06NOV92
PRODUCT:Xtrieve PLUS
PRODUCT VERSION:v4.1x
SUPERSEDES:NA
SYMPTOM
Status 207, 240 and other various errors
ISSUE/PROBLEM
Problems such as status 207s (Field Does Not Exist in Dictionary) and status 240s (Field in the View Definition Is Not in the Active Dictionary) have been identified when attempting to add fields to a view and when recalling views using Xtrieve v4.10 or v4.11. The problems have come about when using Xtrieve with corrupted DDF files.
SOLUTION
In the Xtrieve PLUS User's manual (for DOS and OS2), Appendix D, there is a listing of Dictionary Structures for all of the DDF files. For Xtrieve PLUS for NetWare SQL users, the Dictionary Structures are shown in Appendix C. Each description lists the field and index names for each DDF file. Specifics are given for field data types and sizes, and key flags, such as duplicates, case sensitivity, and segments.
Users should compare the manual's definition of the DDF files with the set of DDFs they are using. To view the DDF file definitions in Xtrieve, the CONFIGURE/SWITCHES/DICTIONARY option must be set to YES. Then the DDF file definitions can be viewed through DICTIONARY/SHOW. A comparison should be made of the field and index information. If any of the information does not match exactly, then the DDFs are most likely corrupted.
One more thing to note is that if a Btrieve BUTIL -STAT is executed on the DDF files, the results may not match the dictionary file definitions viewed in Xtrieve if the files are corrupted.
DDF files created with NetWare SQL will have a supplemental index defined for X$Field (FIELD.DDF), but this is only shown in the NetWare SQL Developer's Kit Getting Started manual that shipped with NetWare SQL 3.0. This fourth supplemental index is not shown in the Xtrieve PLUS User's manuals and is only defined when the dictionaries are created with NetWare SQL.
Following is a method for recovering corrupted data dictionary files:
1.Using XQLI or any other SQL statement processor, execute the following statement to extract the file names from the dictionary files and save the output to an ASCII file:
SELECT XE$NAME FROM X$FILE (to extract file definition names)
Edit the ASCII file so that it does not contain any of the dictionary file names (X$File, X$Field, etc.)
2.Edit the ASCII file so that each file definition is recoverable using MAKE_XTA and XCFP as follows:
The result from the above statement was:
FILEDEF1
FILEDEF2
FILEDEF3
Edit the ASCII file to look like this (you may have to cut and paste quite a bit, but it is worth it if you have many files!):
MAKE_XTA /F:"FILEDEF1"
XCFP MAKE_XTA.XTA FILECMD1
MAKE_XTA /F:"FILEDEF2"
XCFP MAKE_XTA.XTA FILECMD2
MAKE_XTA /F:"FILEDEF3"
XCFP MAKE_XTA.XTA FILECMD3
Rename the resulting ASCII file with a .BAT extension.
3.Create a new set of DDF files in another directory.
4.Run the batch file in the directory with the corrupt DDF files. It will create command files, with a .XTC extension, which can be played back against the new DDF files created in Step 3.
5.Repeat steps 1, 2, and 4 to recover view definitions also. Use the following statement to extract view definition names from the corrupted DDF files:
SELECT XV$NAME FROM X$VIEW
FYI:Masking Integer Fields with Decimal Places
FYI
(Note: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information.)
TITLE:Masking Integer Fields with Decimal Places
DOCUMENT ID#:FYI.A.1127
DATE:06NOV92
PRODUCT:Xtrieve PLUS
PRODUCT VERSION:v4.x
SUPERSEDES:NA
SYMPTOM
Decimal point appears two places to the left of where it should be in a report summary.
ISSUE/PROBLEM
Placing a mask on an integer type field such as ZZZ,ZZ9.99 produces a problem in Xtrieve where the decimal point appears two places to the left of where it should be in a report summary field. For instance, when the field's data was 38,470.00, the masked result was 384.70.
SOLUTION
An integer's mask should not include a decimal point. A more appropriate data type, such as Decimal, Float, Money, or Numeric should be used for fields that require decimal places.
