Programming with dBASE - path question

Author

path question

Linda C. Baker

2006-01-12, 8:23 pm

In my application, it uses the dbf tables in the current directory. If I have the same tables in another directory, say for other years such as 2003, 2004, 2005, what is the best way to access those tables to run reports on them, etc.

Can I just use the Set Directory command to change to another directory and then all the forms and reports will use that data instead of the tables in the current directory?

I have not used BDE Aliases before, but have been reading about that. Is that the best way to do this? If so, once you setup the alias in the BDE administrator, how do you tell it which one your application is using? Do you do a set database to command
when the app is opened and then another set database command when the user wants to change to another database?

Thanks.

*Lysander*

2006-01-13, 3:23 am

In article <n7RTjZ8FGHA.1284@news-server>, lbaker@sboa.in.gov says...

> I have not used BDE Aliases before, but have been reading about that. =20
Is that the best way to do this?=20

Yes, this is definitely the best way.

> If so, once you setup the alias in the BDE administrator, how do you=20
tell it which one your application is using?=20

You do not tell the BDE which alias is used by your application. You=20
tell to your application which BDE-alias to use.

There are several ways to do this.
If, until now, you do not want to work with database-objects, you can do=20
it with the command-set for database-access
(Open database/close database/set database to)

--=20
ciao,
Andr=E9

Les Shewchuk

2006-01-13, 8:23 pm

"Linda C. Baker" <lbaker@sboa.in.gov> wrote in message
news:n7RTjZ8FGHA.1284@news-server...
> In my application, it uses the dbf tables in the current directory. If I
> have the same tables in another directory, say for other years such as
> 2003, 2004, 2005, what is the best way to access those tables to run
> reports on them, etc.
>
> Can I just use the Set Directory command to change to another directory
> and then all the forms and reports will use that data instead of the
> tables in the current directory?
>
> I have not used BDE Aliases before, but have been reading about that. Is
> that the best way to do this?

In the long run, the alias is the best way to go. I found that out the hard
way.

>If so, once you setup the alias in the BDE administrator, how do you tell
>it which one your application is using?

As Andre said, you tell the application which alias to use. You can use the
"set database" command, but the OOP Database Object is easier. Another
advantage to the OOP is all databases/alias are available simultaniously,
you do not have to switch between them.

>Do you do a set database to command when the app is opened and then another
>set database command when the user wants to change to another database?

If you use the OOP, no. When you create a database object, you tell the
object which alias to connect to. (this is the fun part) The database object
doesn't care if it is a folder with dbase tables, or an Access database or
MSSQL etc. etc. It is up to the BDE to figure that out. This makes using
the database object uniform through your application. Each database object
is independent of the others and are all available at the same time. This
way you can build forms and reports from data stored in various locations
and formats.

When you use the database and query objects, your application no longer
needs to know or care where the information actually is. And normally, this
information is not available to the program

Going to what you want to do (access past years). Look in the dUFLP (the
dBase User Function Library Project, maintained by Ken Mayer) there is a
program called BDEAlias.cc that contains several very useful functions for
what you want to do.

With these functions, you can check if the aliases are set correctly, and
that key data can be found. You can also make a form that can change where
the alias looks for the tables. If you used the OOP database
objects...again, they don't care where the information is. So your forms and
reports will pull the data from the new locations automatically.

There are just two critical things to remember when you use this trick.
1> Make sure all forms and reports that use the alias are closed before
changing the path.
2> Make sure that the new path contains identical data structures as you
expect.

Very simple really. Or did I just make things clear as mud?

Les Shewchuk

David Stone

2006-01-13, 8:23 pm

Les Shewchuk wrote:

> There are just two critical things to remember when you use this trick.
> 1> Make sure all forms and reports that use the alias are closed before
> changing the path.
> 2> Make sure that the new path contains identical data structures as you
> expect.

My head is swimming here---if the app is networked in an office and files are
being shared amongst users, as long as each local machine has its own copy of
the exe and uses the alias(es) defined for that machine alone, the above
approach works. But isn't it possible to share an alias (exe loaded from
server?), and so will there not be trouble if an alias is re-pathed for one
user?

David

Les Shewchuk

2006-01-13, 8:23 pm

"David Stone" <dlstone@wholegrain.com> wrote in message
news:43C81C78.7A35A5D5@wholegrain.com...
> Les Shewchuk wrote:
>
>
> My head is swimming here---

Going off the deep end. See you at the bottom...
(trust me, this what goes where stuff is hard to follow)

> if the app is networked in an office and files are
> being shared amongst users, as long as each local machine has its own copy
> of
> the exe and uses the alias(es) defined for that machine alone, the above
> approach works.

> But isn't it possible to share an alias (exe loaded from
> server?), and so will there not be trouble if an alias is re-pathed for
> one
> user?

The location of the EXE is not relevant to this. Remember, it's not your
code that accesses the data, it is the BDE that does the work, when asked
for by the dBase Runtime Engine.

When you install the dBase Runtime and BDE on each workstation, you could
have it put the files on a file server (you still have to Install it on each
system, but the files are kept in one spot. The important thing here is
where the keys in the Windows Registry point.)

But this is a BAD IDEA. Yes, it means that if you move the tables, you only
have to change one IDAPI.CFG file and everyone who uses it is done. (which
also causes the problem you are concerned about) But you're not the only
one to make use of the BDE. Quatro Pro, Crystal Reports, Any program that
uses Crystal Reports, almost any application written in Delphi or Borland
C++ that accesses tables all make use of the BDE. Some of them are a little
picky about the BDE. Also, now you have the network as a bottleneck not
just for accessing your data, but also for finding out how to access your
data.

So it doesn't matter if the EXE and the tables are shared by all the users.
As long as the BDE and the IDAPI.CFG file are separate for each user, then
it will work.

The best way to set things up is to use the dBase Runtime installer to place
the Runtime Engine and the BDE on the local machine. After that, it doesn't
matter where your EXE or tables are stored.

Les Shewchuk

Marilyn Price

2006-01-14, 9:23 am

In article <WP26CjJGGHA.1584@news-server>, les@tritonmarine.com says...
>
> But this is a BAD IDEA. Yes, it means that if you move the tables, you only
> have to change one IDAPI.CFG file and everyone who uses it is done. (which
> also causes the problem you are concerned about) But you're not the only
> one to make use of the BDE. Quatro Pro, Crystal Reports, Any program that
> uses Crystal Reports, almost any application written in Delphi or Borland
> C++ that accesses tables all make use of the BDE. Some of them are a little
> picky about the BDE. Also, now you have the network as a bottleneck not
> just for accessing your data, but also for finding out how to access your
> data.
>
> So it doesn't matter if the EXE and the tables are shared by all the users.
> As long as the BDE and the IDAPI.CFG file are separate for each user, then
> it will work.
>
> The best way to set things up is to use the dBase Runtime installer to place
> the Runtime Engine and the BDE on the local machine. After that, it doesn't
> matter where your EXE or tables are stored.
>

This also helps when various network drives are mapped differently for
different users, a frequent occurrence.

--
Marilyn Price
M. P. Data

John York

2006-01-14, 1:23 pm

Another point is that the set directory command is broken in the runtime -
it simply doesn't work

Was reported back in db2k and never fixed.

One of my big complaints about bug priorities - if it works in the IDE is
damn well should work in the runtime

John

"Les Shewchuk" <les@tritonmarine.com> wrote in message
news:SpU$ifIGGHA.1080@news-server...
>
> "Linda C. Baker" <lbaker@sboa.in.gov> wrote in message
> news:n7RTjZ8FGHA.1284@news-server...
I[color=darkred]
>

Richard Perryman

2006-01-16, 8:23 pm

John York wrote:
> Another point is that the set directory command is broken in the runtime -
> it simply doesn't work
>

Add the "set directory" and "cd\path" and you'll be in business without
an alias.

John York

2006-01-17, 9:23 am

Yeah - of course I jumped before I looked

It is set path that doesn't work

sigh - one of the reasons I try and keep my mouth shut (well, usually)

John

"Richard Perryman" < richard@vipindustrie
s.com> wrote in message
news:D2z43ztGGHA.1584@news-server...
> John York wrote:
>
> Add the "set directory" and "cd\path" and you'll be in business without an
> alias.

Linda C. Baker

2006-01-19, 9:23 am

I did notice that. I kept getting an error and couldn't figure out what the problem was. When I compiled it, it worked then. This makes it hard to test things.

John York < johnatbritesidedotne
t> Wrote:

> Another point is that the set directory command is broken in the runtime -
> it simply doesn't work
>
> Was reported back in db2k and never fixed.
>
> One of my big complaints about bug priorities - if it works in the IDE is
> damn well should work in the runtime
>
> John
>
>
> "Les Shewchuk" <les@tritonmarine.com> wrote in message
> news:SpU$ifIGGHA.1080@news-server...
> I
>
>

Sponsored Links