I suggest you create your file with the 3 integer fields, plus a LongVarBinary. From a Btrieve perspective, this will make your fixed record length 20, and Variable=Yes. This accommodates 4 bytes for each integer, plus an 8-byte field for the longvarbinary.
If you are using the Btrieve API to insert data, you would structure your data buffer as
int1 integer;
int2 integer;
int3 integer;
lvblength integer;
lvboffset integer;
lvbdata byte array of 10000;
When inserting data, you would set lvblength = 10000, or, if you only plan on filling in part of the 10000 bytes, you can set it to a smaller number. You would set lvboffset = 20, since the lvbdata always starts at offset 20 in this example.
If you want to do multiple LongVarBinary fields, you need an 8-byte place holder (for length & offset) in the fixed portion of the record for each lvb field. You need to set the lengths & offsets accordingly to match the data segments in the variable portion.
I suggest you do a little test via PCC. Create a table with the following SQL Statement:
CREATE TABLE lvbtest using 'lvbtest.dat'
(int1 integer not null,
int2 integer not null,
int3 integer not null,
lvb longvarbinary not null)
Then, insert a couple of rows:
insert into lvbtest values(1, 2, 3, '12345')
insert into lvbtest values(4, 5, 6, '1234567890123456')
Use Function Executor to look at the resulting Btrieve records. For the first one, you should see the following 23 hex bytes (remember about all the byte swapping...):
01 00 00 00 02 00 00 00 03 00 00 00 03 00 00 00
14 00 00 00 01 23 45
The first 12 bytes correspond to the three integers. Then, you have the next four bytes set to the value 3 representing the longvarbinary length. Then the next four bytes are set to the value 20 (0x14) representing the 0-based offset for the start of the longvarbinary. Then, you have three bytes of longvarbinary data. Your Btrieve application would need to simulate this same behavior.
