Btrieve Error 2301
Anders Friberg
Suddenly we got a funny problem when reporting from a PSQL2K SP3
database using Crystal Reports 8.5.
The symptom is that a particular name of a table seems to create the
problem. Identical symptoms has been reported on two independent
machines, one W98 and one ME, no networks. Some other W98 and NT4
systems work OK.
We have tried to isolate the problem and here is how we reproduce it:
1: Create a new empty database "D1" with one table only using the
script:
CREATE TABLE XCPDAT (
EvID INTEGER NOT NULL,
PieceInfo SMALLINT,
PieceNumber SMALLINT,
Gross INTEGER,
Net INTEGER,
Weight INTEGER,
Width1 SMALLINT,
Width2 SMALLINT,
Width3 SMALLINT,
Defects SMALLINT,
Points SMALLINT,
Pts100m SMALLINT,
Ticks INTEGER,
Class VARCHAR(1))#
CREATE UNIQUE INDEX XCPDAT_I1 ON XCPDAT (EvID)#
2: Create another new empty database "D2" on the same machine using the
same script but table name XCPDAT changed (we have used XCPDAA and
XCPDATA)
Now when we try to add the table to a Crystal report it will fail to add
when the table name is XCPDAT but always OK if XCPDATA. If we add other
tables in the databases these are always working OK.
We run the SQLCON32 test prog from Crystal and it could find the table
XCPDAT but not the column data (see log below). For the db with XCPDATA
everything was OK.
The strange things are:
- Just this specific table name seems to cause the problem
- Identical db with another table name works OK on the same machine!!
- Identical problem on two independent machines
- No problems with same db:s with lower versions of Crystal Reports
There is probably some installation problem on the problematic machines
(they were setup independantly by different people though, one in USA
and one in Portugal...).
I would be grateful for any hints on where to start looking?
Does the error msg "Cannot locate the named database you
specified(Btrieve Error 2301)" explain something? And why does it
suddenly work when the table name is changed??
Thanks,
Anders F
SQLCON32 log:
SQLConnect Successful
ODBC Version is : 03
SQL Driver Name is : W3ODBCCI
SQL Driver Version is : 7.82.197
SQL Driver Supported ODBC Version is : 02
SQL DBMS Name is : Pervasive.SQL
SQL DBMS Version is : 7.82
SQLTables Successful
[Row, Database, Owner, Name, Type]
1 D1, <Null>, X$Attrib, SYSTEM TABLE,
2 D1, <Null>, X$Field, SYSTEM TABLE,
3 D1, <Null>, X$File, SYSTEM TABLE,
4 D1, <Null>, X$Index, SYSTEM TABLE,
5 D1, <Null>, X$Proc, SYSTEM TABLE,
6 D1, <Null>, XCPDAT, TABLE,
SQLColumns Failed
Error Messages:
[Pervasive][ODBC Client Interface][LNA][Pervasive][ODBC Engine
Interface][Data Record Manager]Cannot locate the named database you
specified(Btrieve Error 2301)
On a working system the last SQLColumns reported:
SQLColumns Successful
[Row, Column, Type, Length]
1 EvID, INTEGER, 10,
2 PieceInfo, SMALLINT, 5,
3 PieceNumber, SMALLINT, 5,
4 Gross, INTEGER, 10,
5 Net, INTEGER, 10,
6 Weight, INTEGER, 10,
7 Width1, SMALLINT, 5,
8 Width2, SMALLINT, 5,
9 Width3, SMALLINT, 5,
10 Defects, SMALLINT, 5,
11 Points, SMALLINT, 5,
12 Pts100m, SMALLINT, 5,
13 Ticks, INTEGER, 10,
14 Class, VARCHAR, 1,
15 Type, SMALLINT, 5,
Mike Hovis
Try turning your SQL trace on (through the ODBC administrator) and
reproducing the problem. This should give you much more detail into what
exactly is occurring.
Best regards,
Michael Hovis (remove the NOSPAM from the email to reply)
"Anders Friberg" <anders....@iba.se> wrote in message
news:3C35D97C...@iba.se...
Anders Friberg
Thank you for your answer, I have done that but without finding
something particular, CRW just seems to decide to drop the connection by
a SQLDisconnect at the point where the OK machines start to read column
information.
Unfortunately I have not been able to reproduce the problem on my own
machines so I have to rely on kind help from the customers anfd that can
be a problem too.
An additional info: Our MFC app (CRecordset) is running OK on the
problematic machines w reading and writing the table.
Best regards,
Anders F
Mike Hovis
Mike Hovis
Thanks Anders,
Let's make sure everything is clear:
There are multiple machines with CRW 8.5 installed and PSQL 2000 ( I
noticed your w3odbcci version is 7.82.197 - which is from SP2 and not SP3 -
perhaps mixed versions of DLLs are the problem? ).
Some machines exhibit disconnect problems with CRW, but only on
databases with the table name XCPDAT.
I've been looking at the CrystalDecisions web page, and there is a
document regarding troubleshooting PSQL connection problems. If you are
able to connect through alternative ODBC sources (such as through your MFC
app), than I would recommend looking at the Crystal support pages:
http://support.crystaldecisions.com/communityCS/TechnicalPapers/cr_dbconn_tr
oubleshooting.pdf and
http://support.crystaldecisions.com/communityCS/TechnicalPapers/cr_pervasive
_reporting.pdf
You might also want to try running PCC to see if the check database wizard
runs without error on the problematic database.
Best regards,
Michael Hovis
"Anders Friberg" <anders....@iba.se> wrote in message
news:3C35E273...@iba.se...
Anders Friberg
See below.
Mike Hovis wrote:
> Thanks Anders,
> Let's make sure everything is clear:
>
> There are multiple machines with CRW 8.5 installed and PSQL 2000 ( I
> noticed your w3odbcci version is 7.82.197 - which is from SP2 and not SP3 -
> perhaps mixed versions of DLLs are the problem? ).
Yes, but this is maybe a bug in the DLL:s? I have on my own machine only
DLL:s W3ODBC*.DLL 2001-03-21 from SP3, they say they are 7.90 in the
explorer but still contains the text 7.82 and also reports 7.82 in the
SQLCON32 log...
>
> Some machines exhibit disconnect problems with CRW, but only on
> databases with the table name XCPDAT.
Yeah, and the same machines work perfect if the table happened to be
named something else. All other tables work fine. Only ODBC, not native
connection.
>
> I've been looking at the CrystalDecisions web page, and there is a
> document regarding troubleshooting PSQL connection problems. If you are
> able to connect through alternative ODBC sources (such as through your MFC
> app), than I would recommend looking at the Crystal support pages:
> http://support.crystaldecisions.com/communityCS/TechnicalPapers/cr_dbconn_tr
> oubleshooting.pdf and
> http://support.crystaldecisions.com/communityCS/TechnicalPapers/cr_pervasive
> _reporting.pdf
>
Yes, I have checked these but they cannot explain why the Error 2301
turns up *after* some other operations like SQLConnect has been done
without problems.
> You might also want to try running PCC to see if the check database wizard
> runs without error on the problematic database.
No problems reported from the wizard.
The whole thing seems more like some memory overwrite or uninitialized
memory somewhere, maybe because of some DLL mismatch due to some error
when the customer installed the softwares.
My problem is that I cannot send these PDF:s etc to the customers and
expect them to correct the problems, I guess I was was hoping that the
Pervasive support could come up with something based on the symptoms and
error messages.
My only options so far are to either specify CRW max version 7 for use
with our software or permanently rename the table to XCPDATA, none of
them seems to be completely satisfying...
Thank you again for your kind help!
Best regards,
Anders F
Mike Hovis
There is something suspicious about a dll that has a version in Explorer
different from what is output in the logfile - almost as if there are DLLs
installed that shouldn't be. Have the customer search the hard drive for
more than one copy of w3odbc*.dll. This is just a hunch, of course, but
stranger things have happened.
Best regards,
Mike
"Anders Friberg" <anders....@iba.se> wrote in message
news:3C3627A5...@iba.se...
Anders Friberg
I did that myself last time on my own (working) system, all w3odbc*.dll
was 7.90.230.036 in explorer, still SQLCON32 said 7.82 (and this text
"7.82" is in the dll:s if you do a search for file contents).
I can ask the customers to check but I think they will get the same
result.
LHarvey
From the status codes book:
"2301: The database name is invalid
Not a named database. Verify you have entered a valid database name. "
If it is happening for them and not you, then I suspect it is not in
the DDF files (if you are using the same set), but in the way the
"Named Database" is set up.
Double check the paths in the Named Database settings... They should
be pointed to physically local files, e.g.
c:\application\data\file.mkd
It will give all kinds of strange errors if it points to a UNC or a
mapped drive letter.
To check the DDFs:
select * from "X$File"
and double check the paths that are returned in the XF$Loc column when
added to the Named Database file location setting.
Mike Hovis
This is really odd. Do you have the latest version of SqlCon32, version
2.0.0.17? There's a link:
http://support.crystaldecisions.com/communityCS/FilesAndUpdates/sqlcon32.zip
.asp
It seems odd that it would disconnect right after getting the tables,
maybe some kind of internal error is generated that SqlCon doesn't report to
the end user? Also, if you have a copy of the sql.log file from a troubled
machine, I would appreciate it if you could send me a copy (remove NOSPAM
from my address).
Other than that, I'm stumped. The latest version of SqlCon uses a different
connection method, SQLConnect instead of SQLDriverConnect - perhaps this
will make a difference as well...
Let me know how things work out.
Best regards,
Mike
"Anders Friberg" <anders....@iba.se> wrote in message
news:3C3650D3...@iba.se...
Mike Hovis
email.
A brief summary:
Anders wrote: ---
I just confirmed what I wrote earlier, if you rename the table in PCC
(right click on table name) the problem will disappear.
--------------------------
Summary: This means that the table name causes the problem, and not the
file name. We were trying to find out if renaming the file would solve the
problem as well, but Ander's customer is in a remote area - so it may be
some time before we see a result from this test.
Anders also wrote: ------
The problem: CRW 8.5 cannot read field data if table name is XCPDAT. Is it a
bug in CRW 8.5? Maybe, BUT CRW *7* can read the field info and I think 8.5
work OK for another customer with same SQL scripts but another database
software (not PSQL).
Is it a bug in PSQL then? Maybe, BUT other software like SQLCON32 (or CRW
7!) *can* read the info.
I myself don't think that the fact that DAT once was a commonly used
extension for btrieve files makes it a reserved word. The designer of a
btrieve database could use any extension he wanted, DAT had no special
meaning whatsoever. (BTW, I think BTR was a more commonly used extension?)
It seems more possible that CRW 8.5 uses some ODBC call that: a: was not
used in v 7 or b: is used in a different way in 8.5
--------------------------------
Summary: CRW was able to reproduce this problem, though I don't know of any
problem with DAT as a reserved word. Pervasive doesn't keep copies of all
third-party software that uses Pervasive.SQL so we would recommend to
continue contact with CRW who seem to have a handle on what is going on
here. If a patch that CRW provided was able to solve the problem with
SQLCON32, then perhaps the problem is more likely on CRW's end.
We would love to be more helpful, but without knowledge of how to produce
the problem without using Crystal Reports it is impossible to be sure of
what the problem is.
Best Regards,
Mike Hovis
"Mike Hovis" <mhovis...@pervasive.com> wrote in message
news:QSF_7.5686$iC.188...@newssvr30.news.prodigy.com...