Search results for query: *

First, you should check to see if your installation is patched up to SP3 and SP4 level on both the client and the server. You are definitely using Pervasive.SQL 2000, but maybe not the latest version. Then you need to do a consistency check against the database you are tring to query and see...

You have to use a Btrieve or Pervasive.SQL engine to read the data out of the files unless you want to write an engine yourself in VB to read the files (and for that you would need the file structure). Btrieve 4.0 was a DOS only engine and as such it's probably a very bad idea to use it from VB...

Yes, you are using Pervasive.SQL 7 which requires Scalable SQL Syntax. The current product Pervasive.SQL 2000i uses native ODBC syntax which is a bit different. You can get the docs for Scalable SQL from the Pervasive Web site, www.pervasive.com, and find out how to convert the statement to the...

It is likely that the Excel file is not a native Excel file, but is linked to data in a Btrieve or Pervasive database engine. That Btrieve file and the engine are probably the native database behind whatever application created the data in the first place. Find out what application generated the...

In order to attache a Btrieve table, you must have good DDFs or you will have to create DDFs yourself which can be a very difficult task. It is easiest to get the DDFs from the application vendor since they are the ones who created the data layout of the tables and know it best. You should then...

Crystal Reports also provides column level security via "Infoviews" so you should be able to do it at the Crystal level, and at the SQL level with groups, users, and views. Regards, Pervasivite

Ric, you should go to the Pervasive Developer Center and join to get a copy of the latest SDK. It has samples for all of this. You can also use Pervasive's DevTalk forum to get samples from PVSW staff. Regards, Pervasivite

Pervasive.SQL 7, and indeed any software that Pervasive has ever released does not have messages that need to be upgraded. I have often had MS software, Win2K specifically, tell me that an udpate was needed, but you should be able to turn that functionality off. I don't see why that would cause...

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...

It's unlikely that the .idx files are Btrieve, though it is possible to make index only files, it's not a common approach since Btrieve files usually contain all their own indexes. Yes, you can access the files without DDFs, however, none of the non-indexed fields will be defined, so you have...

If you lock the users out with an owner name (except for access through the application) and then set up users and groups via SQL security, you can then only allow users access to certain views of the data thus excluding the fields that you don't want them to see. If the data designed by the...

There are several 3rd party tools, each of which has problems, however, the tools that Pervasive typically uses are Butil.exe and the 32-bit Function Executor. Any tool reading the data files directly will only get the data type for the indexed fields. All the other fields you have to guess at...

We found something like this with Access which also uses the JET engine and it opens two handles to the file, one in read/write mode and one in read-only. This is a property of the application telling our engine how to open the file and we see it most often when developers are trying to updating...

Your old Btrieve DOS application should interface directly with Pervasive.SQL to get access to the data, so you don't need to edit the registry. Take a look at the Docs and check our the BtrBox95 for NT. That should also work under XP. You can also check the Pervasive Web site for their...

First off where are you running this query? Are you sure that TNXDTE_72 is stored in datd format and not timestamp or some other way? What kind of data type is TNXDTE_72? Also are you sure there records where both conditions are met? You could also have bad DDFs. You can try similar queries...

What development environment, interface, DLLs, and headers are you using? Wbtrcall.dll, Wbtrv32.dll, W3btrv7.dll???? It's certainly possible that you have run into a memory leak, but not terribly probable since there are literally thousands of developers using Pervasive.SQL 2000 and 2000i that...

All the info you should need is probably in the What's New documentation or in the SDK which is downloadable from the Web. There has been an evolution in the Relational engine since it was really just a driver in the Btreive days, but the good news is that it is now a full ODBC native relational...

There is one other possiblity. You may have installed Pervasive.SQL 2000i over an older version of Pervasive.SQL or Btrieve 6.15 and it picked up the old settings. Since it is 2000i then there is no place in the PCC to change these settings to the default, so you have to go into the registry to...

You are probably quite correct in being cautious about OleDB and you should stick with ODBC until you have thoroughly tested the OleDB. If the queries are complex and used for things like reporting them ODBC is probably going to be your safest bet and also get the best performance in most cases...

You should update to SP which is also Pervasive.SQL 2000i and then test your stored procedure in the SQL Data Manager. After that test it from your application. There are several updates to PDAC that you can get if you contact Pervasive Support or make a post on the Developer's Forum on the...