Q35654: "Bad Record Length" if PUT#1,,x$ where x$ Length = Buffer Size
Article: Q35654 Product(s): See article Version(s): 4.00b 4.50 Operating System(s): MS-DOS Keyword(s): ENDUSER | B_BasicCom | mspl13_basic Last Modified: 16-DEC-1989 The following information about random file I/O with a variable-length string as the third parameter to a GET or PUT was taken from the UPDATE.DOC file for QuickBASIC Version 4.00b: "The PUT statement encodes the length of the string and stores it as the first two bytes of the string. The GET statement uses this encoded value to determine how many characters to read." This behavior of PUT and GET applies to Microsoft BASIC Compiler Versions 6.00 and 6.00b and for MS-DOS and MS OS/2, to Microsoft QuickBASIC Versions 4.00b and 4.50 for MS-DOS, and to Microsoft BASIC PDS Version 7.00 for MS-DOS and MS OS/2. This behavior of PUT and GET is different than in QuickBASIC Version 4.00, where the string length is not recorded by PUT or used by GET. This behavior only applies to variable-length strings, not fixed-length strings. The third argument of the PUT and GET statements was introduced in QuickBASIC Version 4.00, and is not found in earlier versions. Note: You will get a "Bad Record Length" error at run time in a QuickBASIC Version 4.00b or 4.50 program that uses a variable-length string with a length equal to the record length of the OPENed random-file buffer as the third parameter of the PUT statement. Because the two-byte string length is written to the file in addition to the string itself, the record length specified in the "LEN=" clause in the OPEN statement must be at least two bytes longer than the variable-length string used as the third argument in a PUT. Using a third parameter on the PUT or GET statement is not supported in versions of QuickBASIC earlier than Version 4.00. When you PUT with a third parameter in a QuickBASIC Version 4.00 program, the length of the string variable is not written; thus you can PUT a string that is equal in length to the random-file buffer size without error. However, to ensure compatibility with later versions, you should add two bytes to the OPENed random-file buffer size. The following example works in QuickBASIC Version 4.00, but gives a "Bad Record Length" error at run time if compiled in QuickBASIC Version 4.00b or 4.50, or in Microsoft BASIC Compiler Version 6.00, 6.00b or 7.00: OPEN "junk.dat" FOR RANDOM AS #1 LEN = 15 FOR k = 1 TO 5 'The following string is 15 characters long: a$ = "123456789012345" PUT #1, k, a$ NEXT k The following example, which adds two to the record-length value in the LEN= clause, works correctly in QuickBASIC Versions 4.00, 4.00b, and 4.50 and in Microsoft BASIC Compiler Versions 6.00, 6.00b and 7.00: OPEN "junk.dat" FOR RANDOM AS #1 LEN = 17 FOR k = 1 TO 5 'The following string is 15 characters long: a$ = "123456789012345" PUT #1, k, a$ NEXT k This technique should be used to ensure compatibility with releases later than Version 4.00. If you use a variable-length string as the third argument of a PUT statement to write to a random access file in QuickBASIC Version 4.00, then reading that record in QuickBASIC Version 4.00b or 4.50 may give you a "Bad Record Length for GET" error, or string input of the wrong length. This occurs because GET in QuickBASIC Versions 4.00b and 4.50 interprets the first two bytes after the variable-length string as the length, but Version 4.00 did not put the expected two bytes there. To work around this compatibility issue, you can modify your Version 4.00b or 4.50 program to GET into a fixed-length string of the correct length.
THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.
Copyright Microsoft Corporation 1986-2002.