Clipper ODBC Question
Deane Barker
software stores all its data in a bunch of files with these extensions:
DBF
CDX
FPT
IA
I'd like to be about to query these files through an ODBC driver. I've
had some success using a Visual FoxPro driver on the DBF files, but it's
buggy.
I asked the guy who programmed the software, and he responded with just
this:
"try dclip"
What does this mean? I've done a lot of searching, and I'm wondering if
this has anything to do with Clipper. Where can I find an ODBC driver
for these files?
Deane
Stephen Quinn
The ODBC Fox driver should read these files as is.
You might check the first byte of the DBF header, it should be F5h (245) for the ODBC drivers to
read the memo files correctly.
DClip is an excellent Clipper library from Roger Donnay - http://www.dclip.com
--
HTH
Steve Quinn
Deane Barker
I downloaded DClip, but I can't figure out where the ODBC driver is.
There's a DOS app, but that's all I could find in there.
The FoxPro driver will read all the tables except one, for some reason.
The largest table has 220+ rows, which I think is party of the problem.
This one table, it won't even recognize it as a table -- says it can't
found.
This is why I didn't think I was using the correct driver.
Deane
Stephen Quinn
> I downloaded DClip, but I can't figure out where the ODBC driver is.
> There's a DOS app, but that's all I could find in there.
DClip doesn't have an ODBC driver.
You use a dev tool (Eg VB, Delphi, VC, etc..) that supports ODBC (Fox driver) to read the DBF/FPT
pairs.
Get the trial version of cmVODBX32 (or VODBX32) to read the files if you don't want to write code.
- http://www.rayonline.com/jrinfo/
--
HTH
Steve Quinn
Deane Barker
Deane
Jamie Macleod
--
Composed with Newz Crawler 1.4 http://www.newzcrawler.com/
Deane Barker
The Visual FoxPro driver works fine for every table but one. If I run this:
SELECT * FROM investor
I get 5,091 records back. Perfect. If I run this:
SELECT * FROM property
I get:
"Microsoft OLE DB Provider for ODBC Drivers: [Microsoft][ODBC
Visual FoxPro Driver]Not a table."
But it's no different than "investor" -- I can open the data folder and
see "investor.dbf" and "property.dbf" sitting right there next to each
other.
This manifests itself in other ways too. If I try to link tables in
Access or import to SQL Server through the ODBC connection, when the app
shows me the list of tables, "property" is nowhere to be found, although
every other table is sitting right there. The ODBC driver just refuses
to accept that this one file is a table. It ignores it in every case.
This is not computer-specific. I have documented this problem on three
separate machines.
I have tried changing the collating sequence from the "Machine" to
"General" (and a couple others just for fun). No luck (and, to be
honest, I didn't have the first clue what this was doing).
I am using version 6.0 of the ODBC provider for FoxPro. I looked ahead
and found that FoxPro is up to 8.0, but there's no ODBC driver past 6.0.
The 8.0 OLE DB driver needs an actual FoxPro file (.DBC) whereas this
is a "freetext" directory.
I'm lost on this.
Deane
Stephen Quinn
> So the FoxPro driver is the primary ODBC driver for these files?
Depends on which dev tool you use - but yes.
The DBF/FPT pairs are usually FoxPro compatable so the Fox ODBC drivers are the ones to use.
Note: The FPT files may be using a BLOCKSIZE other than the default (33 bytes), so the ODBC drivers
won't/can't read them if they were created with a different size (Eg 1, 32, ??).
Also take into account the DBF header byte as I said in a previous post.
Have a look at the FPT file with a hex editor - bytes 7 & 8 from the start of the file are the
blocksize in hex.
--
HTH
Steve Quinn
gabor salai
news:vm567g8...@corp.supernews.com...
> Here's my problem:
>
> The Visual FoxPro driver works fine for every table but one. If I run
this:
>
> SELECT * FROM investor
>
> I get 5,091 records back. Perfect. If I run this:
>
> SELECT * FROM property
>
> I get:
>
> "Microsoft OLE DB Provider for ODBC Drivers: [Microsoft][ODBC
> Visual FoxPro Driver]Not a table."
>
> But it's no different than "investor" -- I can open the data folder and
> see "investor.dbf" and "property.dbf" sitting right there next to each
> other.
are you sure that "property" isn't reserved word, so maybe, you can't
have/access table called "property"?
maybe to rename it?
Steve Lupton
written in Clipper in the late 80's by Tim Creagh right here in San Diego,
California, USA. I actually did some work for an early Windows version
around 1991/2.
REA used a Clipper\FoxPro variant of xBase for it's database.
Unfortunately, there isn't a good ODBC interface for this flavor of xBase.
As you found out, FoxPro ODBC isn't 100% compatible.
In an xBase database the files with .DBF extension are tables; .FTP
extension are memos (large text fields); .CDX extension are the indices.
.IA is not standard, but may be an interface/config file for SIx triggers.
It's entirely possible there may be odd memo block values or functions in
indices that prevent the standard FoxPro ODBC to recognize all of your
tables. REA does have an export option, but I assume you're looking for an
ODBC driver to use in conjunction with REA using live data. Unfortunately,
no such ODBC driver exists.
"Deane Barker" <de...@deanebarker.net> wrote in message
news:vm4qku4...@corp.supernews.com...
Marco
run fine under Windows 98 SE I have created a System DSN so i can read and
write data. The tables (DBF) the indexes (CDX) and memos fields (FPT) are
updated correctly. In my program i have a lot of databases >200.000
rows.Your problem seem to be a corruprion of the database "property" can REA
read and write correctly data on this database?
"Deane Barker" <de...@deanebarker.net> ha scritto nel messaggio
news:vm5426c...@corp.supernews.com...
Marco
run fine... Why you say to use 33 Byte? And why my application is running
fine? may i have lost same data in the memos?
Thanks, Marco
"Stephen Quinn" <squ...@brutecom.com.au> ha scritto nel messaggio
news:bju6c4$nhbfb$1...@ID-88745.news.uni-berlin.de...
lawrence
DClip I believe is avail from a company called Donnay Software
available free on the web
Stephen Quinn
> Im reading and writing data with ODBC with a block size of 32 Byte and all
> run fine...
> Why you say to use 33 Byte?
That's what is quoted in the Flexfile 3 manual as the default value used by FOX.
I've written several Flexfile2 (.DBV) to DBFNTX (.DBT) and Flexfile3 (.FPT) converters.
What I've found is that converting these memoes to .FPT (Flexfile3, Fox compatable) the ODBC drivers
and Foxpro sometimes won't read the converted files unless the first byte in the DBF header is
F5h(245) and a blocksize of 33 bytes is used.
> And why my application is running
> fine? may i have lost same data in the memos?
No idea - I don't use FOX or ODBC (although I'll install them when I put VS.NET on a machine).
YMMV
--
HTH
Steve Quinn
Steve Lupton
was still a FoxPro variant. REA appears to be written in VB3 using
Successware's SDE version 2x for data access. This is an old data driver
from Successware that allowed Clipper and VB to use the same database
simultaneously. Vista Software's Apollo is the current product with the
same capability. This includes OLEDB libraries for VB, Delphi and other
languages, but no ODBC driver.
I also found that both the Property table and the Tenants table can't be
opened using FoxPro. I suspect this is by design as a method of controlling
access to these tables only through REA. A form of copy protection, I
imagine. Both of these files open fine using dClip using the SIx driver and
VisNav (a utility supplied by Successware) using the CDXFOX driver.
I didn't find anything especially odd about either of these tables and
neither used the encryption feature available with SIx and SDE, I
experimented with the structure by removing the memo fields. That fixed
Tenants, but not Property. I did notice Property had over 350 fields, which
I believe will make it useable only through Clipper - I believe all other
forms of xBase still have a max of 256 fields in a table.
HTH,
-Steve
"Deane Barker" <de...@deanebarker.net> wrote in message
news:vm4qku4...@corp.supernews.com...