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!
What are the most common problems with Pervasive Betrieve (pre SQL) 1
- Thread starter dasa
- Start date
-
1
- #2
What is your artical about. It sounds like you are looking only for problems. Of course you should start with the spelling Btrieve not Betrieve. Also Pervasive now owns Btrieve and there site is which would be a good place to start with information.
I've worked with it for 10 years. It is a very stable and fast database with very very few file corruptions.
As a database it is very good. As a company they have changed directions a few times over the years, but appear to be back on track.
They dropped XQL which was another API set without much notice and made many developers upset including myself. It made one of my programs obsolete overnight.
That's my input,
Gil Gil
I've worked with it for 10 years. It is a very stable and fast database with very very few file corruptions.
As a database it is very good. As a company they have changed directions a few times over the years, but appear to be back on track.
They dropped XQL which was another API set without much notice and made many developers upset including myself. It made one of my programs obsolete overnight.
That's my input,
Gil Gil
Pervasivite
Instructor
As Gil said there is lots of information on Pervasive.com, but I'm really curious why you only want problems? Are you working for a competitor? Will you post the paper as a FAQ here when you get a rough draft?
The main problems with it are:
1) Conflicts with multiple versions of Btrieve or mixed and matched components.
2) Users who don't know how to configure it or update it properly and who really don't understand client/server databases or even peer to peer databases.
3) Use of Btrieve on newer platforms, OSes, and hardware that it was ever tested on. Pervasive stopped testing Btrieve on the latest OSes and hardware in 1998.
Pervasive's flagship product, Pervasive.SQL 2000i has complete native support for all Btrieve data and applications built in and there are very few problems at all with Pervasive.SQL 2000i except for lack of knowledge of the product and it's uses or use beyond it's intended design capabilities.
Regards,
Pervasivite
The main problems with it are:
1) Conflicts with multiple versions of Btrieve or mixed and matched components.
2) Users who don't know how to configure it or update it properly and who really don't understand client/server databases or even peer to peer databases.
3) Use of Btrieve on newer platforms, OSes, and hardware that it was ever tested on. Pervasive stopped testing Btrieve on the latest OSes and hardware in 1998.
Pervasive's flagship product, Pervasive.SQL 2000i has complete native support for all Btrieve data and applications built in and there are very few problems at all with Pervasive.SQL 2000i except for lack of knowledge of the product and it's uses or use beyond it's intended design capabilities.
Regards,
Pervasivite
Hi,
Actually, I have a problem related to it. This might be only related to settings but I don't know.
We have COBOL and we use COBOL module to access btrieve. Just this week, I was modifying a program to use transaction. So, I did turn logging off, open the files, start transation logging, writes to tables, then if our data validation returns error, program will then abort the transaction.
The problem is that the transaction did abort with no error but some records were committed. Have any of you encounted this before? If so, what was the solution?
It seems to only happen if records inserted is more than 7 - 8 records in a table.
Thanks and regards.
Actually, I have a problem related to it. This might be only related to settings but I don't know.
We have COBOL and we use COBOL module to access btrieve. Just this week, I was modifying a program to use transaction. So, I did turn logging off, open the files, start transation logging, writes to tables, then if our data validation returns error, program will then abort the transaction.
The problem is that the transaction did abort with no error but some records were committed. Have any of you encounted this before? If so, what was the solution?
It seems to only happen if records inserted is more than 7 - 8 records in a table.
Thanks and regards.
- Status