SBT consists of layers of old, not as old, newer, and new code and designs. From a user's point of view it's feature rich. The reason you hear all the bad comments is the same reason that we struggle with SBT: they don't have much consistency in the programming style, and their stuff can be hard to figure out. Our general approach is to try and work with data as much as possible, rather than with their code. In other words, when possible, manipulate the data with your own applications and stay away from their transaction processing.

CAUTION: Relational design must have come about after SBT got started, since they don't seem to be very good at it. Be very careful when trying to hard wire multi-table transactions.

GOOD NEWS: Every module in SBT supports a "recurring entry" function of one sort or the other. How they stumbled onto this, I don't know. And why they don't adopt a similar approach for all transactions, I also can't guess. What this lets you do is stuff flat file with all the info you need to spoon feed SBT a transaction, say an invoice, GL posting, or sales order, etc. Then, when you "generate recurring entries", SBT will pick up your entries and do all the relational crunching properly. You can flag your enties in the table to only occur once, so they don't uncontrollably recur.

ODBC: I've been working with a way to help bring SBT tables into modern reality. In control panel, create ODBC data sources for your SBT directories, using FoxPro free tables. In VFP 5 (for Pro) or VFP 6 (for VP 10), create remote views to the ODBC data sources. Then, SBT tables can participate in DBC containers as remote views.

Anyway, SBT is a viable approach if you put up with the strange coding, and use some creativity. You do get all source cheap.

Steve DeMartino