Dbase3 Conversion

[K.taylor]

Hello,

I am the head of a small non profit (501c3) feline registry that
several years ago had a dbase program created to keep track of members,
cats, registration numbers, etc. The son of the original founder wrote
the program, and ive been trying to convert it to Access. I can get to
all the data, the problem lies in that I cannot access the indexes to
know how all the data fits together as the person who wrote the program
no longer has the original files. the program, in it's entirety,
including all the data, is less than 2 Mb. Would anyone be willing to
point me in the rifght direction to anyone who would be willing to do
the conversion for a nomial fee, or failing that, tell me what tool i
would require in order to do it myself. I have tried a couple of
"freeware" conversion utilities that did not work. there is an .exe
file that would probably need to be decompiled in order to find what im
looking for.
Any help would be greatly appreciated!
Thank You
Ken Taylor
President
AACE Inc.

[Rick Wannall]

If you don't mind sending me the dbase data I'll be happy to analyze it for
you for free.

I'll be happy to post what I find out about the data back here into this
group so that someone else could take it on if necessary.

[Bob Quintal]

"K.taylor" <ke*@sandkats.com> wrote in
news:11**********************@j33g2000cwa.googlegr oups.com:

Hello,

I am the head of a small non profit (501c3) feline registry
that several years ago had a dbase program created to keep
track of members, cats, registration numbers, etc. The son of
the original founder wrote the program, and ive been trying to
convert it to Access. I can get to all the data, the problem
lies in that I cannot access the indexes to know how all the
data fits together as the person who wrote the program no
longer has the original files. the program, in it's entirety,
including all the data, is less than 2 Mb. Would anyone be
willing to point me in the rifght direction to anyone who
would be willing to do the conversion for a nomial fee, or
failing that, tell me what tool i would require in order to do
it myself. I have tried a couple of "freeware" conversion
utilities that did not work. there is an .exe file that would
probably need to be decompiled in order to find what im
looking for. Any help would be greatly appreciated!
Thank You
Ken Taylor
President
AACE Inc.

In dBase III, dBase IV, FoxBase+, FoxPro I, and Clipper, indexes
had to be defined manually to put the data recorrds in anything
except the order they were created in.

Access is much smarter than that. Define a relationship, click
on the sort by for a field, create an order by clause in a
query, and Access will automagically create any needed index.
--
Bob Quintal

PA is y I've altered my email address.

[Rick Wannall]

Access is pretty slick, but it doesn't exactly "automagically create any
need index."

If you mean that it can sort easily through the interface, you're absolutely
correct.

To create an index, however, you must tell it to do so. This happens in the
table design view. If you mark a field as Primary Key, it makes an index to
implement that. If you mark a field as indexed (whether with or without
duplication allowed), it creates an index for that.

In code you can access a TableDef object and append a new Index object to
create more indexes. Those indexes show up in the popup Indexes windows,
where you can manually create more indexes. You must use either code or
this window to create indexes based on more than one field.

None of this exactly solves the poster's problem of finding correspondences
between fields in different tables. One would hope that the primary key in
one table would be carried into a field of the same name as a foreign key in
any related table, but even that must sometimes be violated. For instance,
if you have a Parts table, using PartID as the primary key, then in your
assembly table, where you pair one Master part with 1 to n Component parts,
you cannot use the field PartID twice, clearly. Typically, you prepend or
append some distinguishing text, such as Assembly_PartID and
Component_PartID, or PartID_Assembly, PartID_Component.

So, some analysis is needed in coming forward from dbase-era data to Access.
Sometimes not much. It has always been possible to design tables well and
to design related tables properly. If the original designer did that, the
analysis required in the conversion is minimal.

[Bob Quintal]

"Rick Wannall" <cw******@yahoo.com> wrote in
news:18******************@newssvr12.news.prodigy.c om:

Access is pretty slick, but it doesn't exactly "automagically
create any need index."

If you mean that it can sort easily through the interface,
you're absolutely correct.
and it does so by building a hidden index. If you set a relation
in a query, Access will create hidden indexes on the two fields
if none exist.
To create an index, however, you must tell it to do so. This
happens in the table design view. If you mark a field as
Primary Key, it makes an index to implement that. If you mark
a field as indexed (whether with or without duplication
allowed), it creates an index for that.
Yes, you can create additional indices to improve performance.

In code you can access a TableDef object and append a new
Index object to create more indexes. Those indexes show up in
the popup Indexes windows, where you can manually create more
indexes. You must use either code or this window to create
indexes based on more than one field.

None of this exactly solves the poster's problem of finding
correspondences between fields in different tables.
Actually the SET RELATION TO xxxxx INTO yyyyyy,
is the only way to set up a relation in dBASE III. The statement
is a pretty good clue as to the relationship, as it identifies
the field (or fields) used on one side of the (left) join.It's
then fairly simple to open the joined table and look for values
like those in the identified fields. ,

One would hope that the primary key in one table would be carried into a
field of the same name as a foreign key in any related table,
but even that must sometimes be violated. For instance, if
you have a Parts table, using PartID as the primary key, then
in your assembly table, where you pair one Master part with 1
to n Component parts, you cannot use the field PartID twice,
clearly. Typically, you prepend or append some distinguishing
text, such as Assembly_PartID and Component_PartID, or
PartID_Assembly, PartID_Component.

Calling them Mabel and Bob would be dumb.
So, some analysis is needed in coming forward from dbase-era
data to Access. Sometimes not much. It has always been
possible to design tables well and to design related tables
properly. If the original designer did that, the analysis
required in the conversion is minimal.

Granted. I wrote an app in dbase III, around 1986. Various
employees upgraded to dBase IV, then Access 2, then '97. in
2001, the app was split and tables moved into SQL server. I was
consulted to investigate a modernization of the app, to tie it
into the MRP system. The structure of the system hadn't changed,
even the _dBaseLock fields were there. I deleted those and
added a field named website and a second called email to the
vendors table. No other changes were necessary.

--
Bob Quintal

PA is y I've altered my email address.

[Rick Wannall]

For BQ:
"Bob Quintal" <rq******@sympatico.ca> wrote in message
news:Xn**********************@207.35.177.135...

"Rick Wannall" <cw******@yahoo.com> wrote in
news:18******************@newssvr12.news.prodigy.c om:

Access is pretty slick, but it doesn't exactly "automagically
create any need index."

If you mean that it can sort easily through the interface,
you're absolutely correct.
and it does so by building a hidden index. If you set a relation
in a query, Access will create hidden indexes on the two fields
if none exist.

I'm trying to understand the purpose of this reply. You're referring to how
Access does things behind the scenes. The hidden indexes you refer to are
ephemeral. When you finish your query, the indexes are discarded. The user
cannot see or manipulate them through the index interface. Neither can the
developer through code. You're referring to something that a user will not
see or ever make any use of, except to be the unknowing beneficiary of it.
Why?

To create an index, however, you must tell it to do so. This
happens in the table design view. If you mark a field as
Primary Key, it makes an index to implement that. If you mark
a field as indexed (whether with or without duplication
allowed), it creates an index for that.
Yes, you can create additional indices to improve performance.

In code you can access a TableDef object and append a new
Index object to create more indexes. Those indexes show up in
the popup Indexes windows, where you can manually create more
indexes. You must use either code or this window to create
indexes based on more than one field.

None of this exactly solves the poster's problem of finding
correspondences between fields in different tables.

Actually the SET RELATION TO xxxxx INTO yyyyyy,
is the only way to set up a relation in dBASE III. The statement
is a pretty good clue as to the relationship, as it identifies
the field (or fields) used on one side of the (left) join.It's
then fairly simple to open the joined table and look for values
like those in the identified fields. ,

What you say sounds right, though I haven't seen dbase in so long that I
would have had to be reminded of this somehow. Absent such SET commands, or
other joining techniques used in the application, how would you determine
relationships other than by inspection?
One would

hope that the primary key in one table would be carried into a
field of the same name as a foreign key in any related table,
but even that must sometimes be violated. For instance, if
you have a Parts table, using PartID as the primary key, then
in your assembly table, where you pair one Master part with 1
to n Component parts, you cannot use the field PartID twice,
clearly. Typically, you prepend or append some distinguishing
text, such as Assembly_PartID and Component_PartID, or
PartID_Assembly, PartID_Component.

Calling them Mabel and Bob would be dumb.

And yet I have seen developers call a foreignkey field something that meant
something to them but gave no clue to the corresponding field in the
referenced table. They might as well have called the foreign key fields
Mabel and Bob. There are a lot of people who manage to pass themselves off
as developers, and I've cleaned up behind several of them. People do dumb
things, and decoding them takes analysis.

So, some analysis is needed in coming forward from dbase-era
data to Access. Sometimes not much. It has always been
possible to design tables well and to design related tables
properly. If the original designer did that, the analysis
required in the conversion is minimal.

Granted. I wrote an app in dbase III, around 1986. Various
employees upgraded to dBase IV, then Access 2, then '97. in
2001, the app was split and tables moved into SQL server. I was
consulted to investigate a modernization of the app, to tie it
into the MRP system. The structure of the system hadn't changed,
even the _dBaseLock fields were there. I deleted those and
added a field named website and a second called email to the
vendors table. No other changes were necessary.

--
Bob Quintal

PA is y I've altered my email address.

[Bob Quintal]

"Rick Wannall" <cw******@yahoo.com> wrote in
news:bP*******************@newssvr11.news.prodigy. com:

For BQ:

and it does so by building a hidden index. If you set a
relation in a query, Access will create hidden indexes on the
two fields if none exist.
I'm trying to understand the purpose of this reply. You're
referring to how Access does things behind the scenes. The
hidden indexes you refer to are ephemeral. When you finish
your query, the indexes are discarded. The user cannot see or
manipulate them through the index interface. Neither can the
developer through code. You're referring to something that a
user will not see or ever make any use of, except to be the
unknowing beneficiary of it. Why?

They aren't ephemeral, they are permanent.Access uses them.

Actually the SET RELATION TO xxxxx INTO yyyyyy,
is the only way to set up a relation in dBASE III. The
statement is a pretty good clue as to the relationship, as it
identifies the field (or fields) used on one side of the
(left) join.It's then fairly simple to open the joined table
and look for values like those in the identified fields. ,

What you say sounds right, though I haven't seen dbase in so
long that I would have had to be reminded of this somehow.
Absent such SET commands, or other joining techniques used in
the application, how would you determine relationships other
than by inspection?

Without the SET RELATION commands you have nothing more than a
bunch of freestanding tables. They are the only way in dBase3.
As long as the .prg files are there that's all that's needed to
determine relationships. .prg files can be read in notepad.

And yet I have seen developers call a foreignkey field
something that meant something to them but gave no clue to the
corresponding field in the referenced table. They might as
well have called the foreign key fields Mabel and Bob. There
are a lot of people who manage to pass themselves off as
developers, and I've cleaned up behind several of them.
People do dumb things, and decoding them takes analysis.

I know what you mean. I have had to clean up several self-titled
programmer-analysts.
--
Bob Quintal

PA is y I've altered my email address.

[Rick Wannall]

You've got my interest now. I haven't been able to find any info about
Access building indexes on the fly and having them persist. I looked at KB
Article 209126 (Information about query performance in an Access database)
and simliar stuff, but nothing one way or the other.

I'm still skeptical, because of statement like "Index sort fields/Index the
fields that you use for sorting." under "Tips to improve query performance"
in the article cited above. I would expect a mention somewhere that after
the first run of the query it doesn't matter, since Access builds and keeps
an index anyway.

Well, that only means I haven't seen what I'm looking for.

Can you point me to a detailed source that lays out the process you're
referring to? I'm very eager to know more.

Thanks ahead for any references.

Rick W