BTRCALL versus BTRV

[Roy Bauer]

Anybody out there using CALL BTRV in thier PowerBasic Code. I have seached the Forums and only see examples where BTRCALL is used for Btrieve Calls.

Also, there are 2 different DLL's I have seen used for the DECLARE WBTRV32.DLL and W3BTRV7.DLL. Anyone have any experience with either.

Not sure which to use on my conversion from old DOS code to PBCC.

Roy

[Reinhard Böck]

BTRCALL versus BTRV

I made it this way:

DECLARE FUNCTION BTRCALL LIB "w3btrv7.dll" (BYVAL WORD, ASCIIZ, ANY, INTEGER, ANY, BYVAL BYTE, BYVAL BYTE) AS INTEGER

and used in in this form:

Stat = BTRCALL(%BtStat, bt(Dat%).PosB, StatFileBuffer,_DBLen%,KeyBuffer$(Dat%), 255, Sck)

I hope it helps!

Greetings from austria, europe!
Reinhard Böck

[Don Dickinson]

here's the declaration i've always used:

Declare Function BTRCALL Lib "wbtrv32.dll" (ByVal OP As Integer, _
                                            Pb As Any, Db As Any, _
                                            DL As Integer, Kb As Any, _
                                            ByVal Kl As Integer, _
                                            ByVal Kn As Integer) As Integer

[Roy Bauer]

Hi Don. I have seen that you have weighed in on a number of Btrieve forum questions. The code I have in my current programs is pretty dated, however my Btrieve version is Pervasive SQL 2000i.

I am getting a STATUS 11 when I try to open my file. I am not sure about the conversion. In the current code, I did a BASIC OPEN to file #10, for example and did a FIELD statement FIELD Length AS DataBuffer. I used VARPTR(#10) to point to the addres of the FCBPTR.

Not sure if you recognize any of this, but I can send you what it looks like. I dont think I need any of this anymore, however, I am unsure if I have to put the name of the datafile in the BTRCALL, or the address that points to it.

If you have any perspective on this, I would appreciate it.

[DonDickinson]

hi roy,
given the declaration above, here's how i would open a btrieve file:

dim iDataLen as integer
dim zFileName as asciiz * %MAX_PATH
dim zPosBlock as asciiz * 128  'position block, this is used by btrieve 
Dim dataBuf as asciiz * 1200 'just some empty space, can't recall if its used

zFileName = "c:\whatever\somebt.dat"
iDataLen = 0
iReturn = BTRCALL ( %B_OPEN, _
                     zPosBlock, _
                     dataBuf, _
                     iDataLen, _
                     zFileName, _
                     len(zFilename), _
                     0 )

Per the code above, i pulled it out of a btrieve wrapper that i wrote. i haven't used btrieve in 5 or 6 years, so i can't recall what, if anything, the dataBuf parameter is for. in my wrapper, i don't seem to use it for anything.

here is a link to a page that describes the btrieve status codes in case you don't have a good reference:

https://www.scala.net/sweden/Downloads/faq/btrieve/btrieve_error_codes.htm

[Mike Doty]

Databuf$ is the internal record buffer Btrieve uses for reading and writing.
It is also used to hold parameters when some operations are executed.
Example: LEFT$(DataBuf$,DataLen%) for reads and writes. The DataBuf$
may also need to be long enough to hold variable length records.
Tsunami is used by many of us instead of Btrieve.

[Roy Bauer]

Hi Mike. I have seen some discussion about Tsunami, however, I have a lot of modules that have used BTREIVE for a number of years, so for now, I have to stay on that DB.

If I have a program that has 5 or 6 files open at the same time, Does that imply a different data buffer for each file, or does data come from the different files into the same buffer?

Thanks. Roy

[Mike Doty]

I have earlier Btrieve's, but only some DOS with Btrieve 5.1 handy.
This would be used if FIELD was used instead of a UDT.
This uses a DOS field buffer and points to the first fielded variable using DataSeg and DataOffset. Of course, this isn't the same with the version of Btrieve you are using. I'll search some more.
I think Don posted encapsulation of the Btrieve routines.

filename$ = "MyFile.Dat"
LSET value$ = filename$
BLOCK$(9) = STRING$(128, 0)
Buflen9 = 206
OPEN filename$ FOR RANDOM SHARED AS #filenumber LEN = Buflen9
FIELD #filenumber, BufLen9 AS Dummy$
op = open.it
DataS = SSEG(Dummy$)
DataO = SADD(Dummy$)
CALL MhBtrv(op, status, BLOCK$(9), DataS, DataO, Buflen9, value$, speed)

[Mike Doty]

Can't find my Btrieve for Windows, unfortunately. Had the unlimited run-time for DOS and for Windows and Novell sold out to BTI back then. Switched to Tsunami.

[Roy Bauer]

Hi again, Mike. The code you sent is pretty much like the code in my current programs. I got the Open to work now, However, when I try to get data (GetEqual, or GETGREATER THAN OR EQUAL TO), I get NO BTREIVE ERROR, but nothing back in the data buffer. In the BTRCALL, the argument I pass is F10DATA, which is defined as DIM F10DATA As Asciiz * 44. The record is 44 bytes long. Can you tell me

[Roy Bauer]

Don, your example got me by my OPEN issue. Thanks. I defined my data buffer as
DIM F10DATA As Asciiz*44 (my existing file in this example is length 44.

I pass F10DATA as the variable in the BTRCALL. I print F10DATA out on the return (No btrieve error code) and it contains only the KEY. Any suggestions?

[Mike Doty]

Return = BTRCALL ( Op, _
PosBlock, _
dataBuf, _
DataLen, _
KeyValue$, _
KeyLen, _
KeyNumber )
What is the length of each value above?
What is the value passed in each parameter?
Is PosBlock 128-bytes?
Is dataBuf a UDT?
Is key 0?

[Mike Doty]

http://www.msmiami.com/custom/downloads/Pervasive2001i_VBasic.pdf

[Roy Bauer]

I got that article.
POSBLOCK is 128
Databuf = F10DATA
DataLen = 44
KeyValue = "CONTROLREC"
KeyLen = 10
KeyNUm = 0

I think my issue is your question about dataBuf as a UDT. I am not sure what that is. Can you give me an example. Thanks.

[Mike Doty]

'This should be close

TYPE MyType
  MyData AS STRING * 44
END TYPE
FUNCTION PBMAIN () AS LONG
  DIM udt AS MyType
  LOCAL ret AS INTEGER
  LOCAL hFile AS LONG
  LOCAL KeyValue AS STRING * 64
  hFile = FREEFILE
  OPEN "MyData.Dat" FOR RANDOM AS #hFile LEN = SIZEOF(udt)
  ret =  BTRCALL ( Op%, PosBlock$, udt, dataLen%, KeyValue$, KeyLen%, KeyNumber%)
END FUNCTION

[Mike Doty]

#COMPILE EXE
#DIM ALL
GLOBAL gBlock() AS STRING
DECLARE FUNCTION BTRCALL ( Op%, PosBlock$, DataBuf$, dataLen%, KeyValue$, KeyLen%, KeyNumber%) AS LONG
TYPE MyType
  MyData AS STRING * 44
END TYPE
FUNCTION PBMAIN () AS LONG
  DIM gBlock(1) AS STRING
  gBlock(1) = SPACE$(128)   'set all position blocks to 128-bytes
 
  DIM udt AS MyType
  LOCAL ret AS INTEGER
  LOCAL hFile AS LONG
  LOCAL KeyValue AS STRING
  LOCAL databuf AS STRING
  LOCAL op AS INTEGER
  LOCAL DataLen AS INTEGER
  LOCAL KeyLen AS INTEGER
  LOCAL KeyNumber AS INTEGER
  KeyValue = SPACE$(44)          'be sure length is enough
  databuf = udt
  LSET keyValue$ = "DOE"         'don't change length of keybuffer
  ret =  BTRCALL (Op%, gBlock(1), databuf, dataLen, KeyValue, KeyLen, KeyNumber)
END FUNCTION
FUNCTION BtrCall(Op%,PosBlock$,DataBuf$,DataLen%,KeyValue$,KeyLen%,KeyNumber%) AS INTEGER
  'dummy statement (not needed)
END FUNCTION

[Mike Doty]

Since a UDT is being used, I don't think the OPEN "MyFile.Dat" is needed.

[Roy Bauer]

I see how the TYPE was done. I was under the impression that one did not have to use the DOS OPEN in front of the BTRIEVE calls anymore with PowerBasic.

I will try this, but one clarification. Where does the value of hFile get defined?

[Mike Doty]

You are correct. See my last post.

[Roy Bauer]

I am getting a 44 character string printed out, but other than the first 10 characters, which is the key, there is garbage coming out.

In my old programs i store all the data as character strings, and when I store them or bring them out, I convert them to character strings or back to variables using the CVx and MKx functions. So that should not be a problem?