Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Pros and cons of Btrieve
- Thread starter itguy1
- Start date
Vancouverite
MIS
Much depends on what you are comparing it with. However, a few general comments...
Pervasive is very low maintenance. Once set up, it is frequently not touched again (except for upgrades or backups).
If you are looking at Btrieve rather than Pervasive.SQL (which still supports Btrieve), you should know that this DB is no longer supported by the manufacturer.
Speed: Good. Scalability: Fair. Multi-Platform support: Good. Stability: Excellent. Support: Fair.
The most important consideration (IMO) is whether or not the supplier is using Btrieve or Pervasive.SQL (which includes Btrieve functionality) as the actual DB.
Pervasive is very low maintenance. Once set up, it is frequently not touched again (except for upgrades or backups).
If you are looking at Btrieve rather than Pervasive.SQL (which still supports Btrieve), you should know that this DB is no longer supported by the manufacturer.
Speed: Good. Scalability: Fair. Multi-Platform support: Good. Stability: Excellent. Support: Fair.
The most important consideration (IMO) is whether or not the supplier is using Btrieve or Pervasive.SQL (which includes Btrieve functionality) as the actual DB.
MichaelRed
Programmer
Pros. NONE.
Cons. Not supported. Not Relational. If Accessed via BTrieve, CANNOT be accessed with any other product. Conversley, If Accessed via SQL engines, CANNOT be concurrently accessed via BTrieve. Record locking with BTrieve is problematic. this has caused (or at least made a MAJOR contributionto) at least one POS vendor to go 'belly up'.
I have a PILE of VB code used to generate class modules for BTRieve files. Basically abandoned by the POS vendor when he went belly up. Altogether, I can only say that I would RUN, not walk away from BTRieve. [red]IF[/red] you feel this is in your future, you need to belooking at alternatives to BTRieve for the database platform, you need to be looking at the requirements for POS systems (along with how well the system you are interested in meets these requirements) and WHY the system is available (did it go belly up? If so Why? What are the STANDARD business merics for this business (product). The system I am aware of had a 'cost of ~ $40K for a six to ten station installation. Hardware costs were over half of this ammount, set up trainning ... accounted for another 25%. Marketing ~ 10&. the vendor was not able to sell more than about 10 to 15 systems per year. Staff requirements included four full time programmers. BROKE.
This specific system did NOT support multiple inventories, so was not suitable for multi-store cross-sellling, which was a severe limitation in today's market. While this was not strictly attributable to BTRieve, the vendor was not able to make changes to the database schema to incorporate this feature without re-writing significant portions of the code, with an estimate of more than four man-years of effort to complete thte task.
Another limitatioon was in the report generation facillity. It DID allow the generation of custom reports, however the process was so clumsy and crude that only about 5% of the customer base ever generated any custom report. Again, I attribute this to the probems witth BTRieve, which more or less dictated that the table relationships all be pre-defined.
In retrospect, the only way the business survived was the fact that the owner had other businesses to fund the development and he had two 'chain' store customers. Within the last year, both of the chains opted for systems which included features not available from this vendor.
I don't mean to be totally negative, BUT ... POS systems are some of most difficult to maintain and have a relatively low profit margin. BTRieve is NOT (IMHO) a good choice (as the database engine) for the application.
MichaelRed
redmsp@erols.com
There is never time to do it right but there is always time to do it over
Cons. Not supported. Not Relational. If Accessed via BTrieve, CANNOT be accessed with any other product. Conversley, If Accessed via SQL engines, CANNOT be concurrently accessed via BTrieve. Record locking with BTrieve is problematic. this has caused (or at least made a MAJOR contributionto) at least one POS vendor to go 'belly up'.
I have a PILE of VB code used to generate class modules for BTRieve files. Basically abandoned by the POS vendor when he went belly up. Altogether, I can only say that I would RUN, not walk away from BTRieve. [red]IF[/red] you feel this is in your future, you need to belooking at alternatives to BTRieve for the database platform, you need to be looking at the requirements for POS systems (along with how well the system you are interested in meets these requirements) and WHY the system is available (did it go belly up? If so Why? What are the STANDARD business merics for this business (product). The system I am aware of had a 'cost of ~ $40K for a six to ten station installation. Hardware costs were over half of this ammount, set up trainning ... accounted for another 25%. Marketing ~ 10&. the vendor was not able to sell more than about 10 to 15 systems per year. Staff requirements included four full time programmers. BROKE.
This specific system did NOT support multiple inventories, so was not suitable for multi-store cross-sellling, which was a severe limitation in today's market. While this was not strictly attributable to BTRieve, the vendor was not able to make changes to the database schema to incorporate this feature without re-writing significant portions of the code, with an estimate of more than four man-years of effort to complete thte task.
Another limitatioon was in the report generation facillity. It DID allow the generation of custom reports, however the process was so clumsy and crude that only about 5% of the customer base ever generated any custom report. Again, I attribute this to the probems witth BTRieve, which more or less dictated that the table relationships all be pre-defined.
In retrospect, the only way the business survived was the fact that the owner had other businesses to fund the development and he had two 'chain' store customers. Within the last year, both of the chains opted for systems which included features not available from this vendor.
I don't mean to be totally negative, BUT ... POS systems are some of most difficult to maintain and have a relatively low profit margin. BTRieve is NOT (IMHO) a good choice (as the database engine) for the application.
MichaelRed
redmsp@erols.com
There is never time to do it right but there is always time to do it over
- Status