Ed,

You mean the table that aren't wrapped by a database and store duplicately structured data in history files? As you can tell I'm not a big fan of SBT. But then again my company made the decision to do more than just look at SBT data. Look but don't touch is my motto when it comes to SBT.

I'm anxious to see what Evan is talking about.

>>Ed,
>>
>>If you're going to try to get anything from the SBT code you are wasting your time. It is complete spaghetti. Also I think Pro Series 6 of SBT is out and claims to be object oriented. From what I've heard on this forum they have saved the forms as classes and called it object oriented. We had a demo of Accountmate and it seemed from the little we tested it that it was fairly easy to subclass but you don't get all the code even if you pay for the source. There have been many threads here on both these products and I have never heard a good statement about SBT from a programmer's perspective.
>>
>
>It's not spaghetti; no self-respecting pasta would have that much macroexpansion in it. It's holdover dBASE III code that shows its roots badly. It is workable, but requires a distinctly different mindset than what VFP has built into most people today. The one thing that is adequately documented is the data fields in their tables.
>
>VAM is OK as long as you don't need to get inside the guts of the accounting system, or if you want to change the behavior of UI elements on other than an instance basis. Interfacing with it is pretty easy if your needs are met bytheir import facilities. They've announced an SDK to simplify integrating with other apps; I've not seen it, and I'm tired of being told "Real Soon Now".