Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Prevasive and VB 432 bit code

Prevasive and VB 432 bit code

Prevasive and VB 432 bit code

Hi all! I have VB 4 32 bit code (I know, but we are small company!) that is only slightly modifed from exactly similar code (that works flawlessly) in another application-I added some file constants and definitions that this new app needs. Code mostly follows the examples provided by Pervasive API for using Visual Basic. I use an array of type string for the position blocks- the 22 entries of 128 bytes each is the biggest offender for space usage. Each file has it's own buffer defined, etc.

The application does data verification(not empty, valid for the tables/fields, etc) BEFORE doing any record commits. Record commits consist of updates in existing records and insertion of new records.

Issue: Performing the operations too many times w/o restarting the program caused error 28 out of stack space errors. Each operation consists usually of file updates at most on 4 records, at most I have seen up to 12 records.

Issue: Subsequent error code modifications to catch error 28  errors yield a program that simply DISAPPEARS at random, e.g. when closing a form after doing some file manipulations, updates or insertions; it is not visible in Task manager or via any other excellent process viewers(SysInternals) and can be restarted (with similar results :( )

The code compiles to less than 512K.

There is only one exit point for the entire program and it is only called from a main form when a specific button is clicked.

Begin, End Transaction are used to keep the files in sync, and Abort Transaction if any errors arise to roll back errors.

There is no explicit recursion. Have checked controls' Click() code and moved/removed code in an attempt to find/avoid the dreaded 'black hole recursion' that occurs when events are called that call events that call events that .... - I might still have some, but I put in a logging function (in EVERY routine!) and did not get anything that looked out of the place; everything opened/occurred/closed in normal sequence.

I DO use constants, but again the code is nearly identical to code in (an)other app(s) that never fails. I did attempt to remove these constants and use literals instead - same result.

Running compiled code or executing via the IDE gives the same results.

I have not yet attempted to step through the code line by line, and will do so ASAP, but am loath to do so as it would take probably as many hours to generate the error as I have already spent tracking down the problem!

Any ideas? This has already taken way too much of my time for what should be a relatively simple application.

RE: Prevasive and VB 432 bit code

Forgot to add:
Pervasive Version
Server = Win2K (NT on develpment side)
Client = XP

RE: Prevasive and VB 432 bit code

Usually when a program disapears, it's crashed.  
In terms of Pervasive, I've seen position blocks that haven't been properly initialized cause crashes.  Personally, I use an array of bytes rather than a 128 byte string for the Position block.  
If you can't narrow down which call causes the crash, then you'll need to step through the code.  

Certified Pervasive Developer
Certified Pervasive Technician

RE: Prevasive and VB 432 bit code

Thanks for the quick reply!

Yes, I assume it's crashed ;) Just never saw it totally disappear!

And I did have pos blocks defined as an array of bytes, didn't seem to make a difference...I'll go back to them because the Pervasive examples use them.

What I have is a generic routine CallBtrieveOperation (gets passed the btrieve opcode, posblk array index and key number). First thing the routine does is open the file with another routine (that is also passed the posblk index). I use an array to indicate if the file is already opened so I don't re-open the file multiple times. So all access to the posblk array is controlled via indexing. The only exception are the Transaction Control Calls, whcih uses it's own position block.

Another side effect at times is that I'll get a crash then a (n) ntdll.dll error.

Well, I guess it's step through the code time! Thanks again, mirtheil

RE: Prevasive and VB 432 bit code

Update: Found one (1) major flaw:
Dim s1 as string * 128
s1 = Space(512)
 This var was only used once at start-up then nevr referenced again.
Fixed it, but still get random crashes.

Stepped through the code line by line; will not crash when stepping through.

The only exception when steppinng through the code is that occasionally when the button on the main form is clicked (calls UnLoadAllForms then Unload Me is the very last statement encountered) I lose the entire IDE, e.g. it "disappears" as is currently happening with the compiled program;not visible in any task list in any way/shape/form.

Small monetary reward offered to whomever can fix this! (mirhteil, are you up to it ? If so, I can go to your website and send you the code :) )

RE: Prevasive and VB 432 bit code

Unfortunately, I don't have VB4 anymore so I would only be able to look at it in the context of VB6.  You might consider just posting up the code for the UnLoadAllForms and also the Form Unload code.

Certified Pervasive Developer
Certified Pervasive Technician

RE: Prevasive and VB 432 bit code

Note -> LogErr(stringvalue) opens a local file for append and immediately closes it
Public Sub UnloadAllForms(FormToIgnore As String)
    LogErr "At: UnloadAllForms"
    On Error GoTo Sub_Err
        Dim F As Form
    For Each F In Forms
        If F.Name <> FormToIgnore Then
            Unload F
            Set F = Nothing
        End If
    Next F
Sub_Exit: On Error Resume Next
    On Error GoTo 0
    Exit Sub
    Message "UnlAF: " & Error$
    Resume Sub_Exit
End Sub
All forms except frmENVOCOptions have this:
Private Sub btnExit_Click()
    LogErr "At: xyz"
    On Error Resume Next
    Unload Me
    On Error GoTo 0
End Sub
and frmENVOCOptions has:
Private Sub btnExitOtherOpts_Click()
    LogErr "At: btnExitOtherOpts_Click"
    CloseBtrieve ' Stop btrieve
    UnloadAllForms Me.Name
    Unload Me
End Sub
  CloseAllBtrieveFiles contains a for next loop that calls btrcall(BCLOSE...) for any file marked open
  CloseBtrieve calls BTRCALL(BRESET then BTRCALL(BSTOP
  CleanUP closes an open file (a global local workstation file is used to swap out the data buffers to fix the alignment problems in VB32) and sets a boolean array (to indicate a btrieve file is already open) to Empty

This is a most irritating problem! Ready to give up my position and go flip burgers for a living...

RE: Prevasive and VB 432 bit code

Well, stepped through the code about a million times - no good. I can step through it and never get a failure. But if I compile it and run or just let it run inside the IDE, it will fail at various times. The newset oddity is one or two operations will work fine, but when I close the app, I get a       'the memory referenced cannot be read' error (not an error report type message or GPF, more like a MegBox). Looks like a memory leak, but I'll be darned if I can find it.
I have logged output and not seen any run away recursion.
I have verified data structures are of adequate length (btrieve complains about that anyway!) and routines that hit these structues have been checked to see that I'm not writing beyond the variables' length.
I have verified parameter types match what is expected, and tried CLng and CInt to force types when using variables in calls.

Any other suggestions would be greatly appreciated. I'd be willing to send the entire Project along to some masochistic person who'd like to torture themselves by looking at it!

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close