Discussion:
Accessing dbf's remotely
(too old to reply)
John Noble
2008-09-23 08:58:04 UTC
Permalink
Accessing dbf's Remotely.



The company which we have been asked to do this work for has several
offices. The main office(HQ) is in the UK while the others are in based all
over Europe.



Currently each office is responsible for producing its own invoices,
statements etc for their respective sales. Therefore, currently each office
writes to its own local database.



The new requirement:

HQ will now be responsible for the producing of invoices on behalf of the
other offices.



My question is this - With as little work as possible, what would be the
best way for the main office to access the data held in other offices?



Possibilities:

1. As well as the European offices writing to a local database (for
their own records), a duplicate entry is written to a mySQL database held on
a web server. This data could then be imported to the main office at regular
intervals. I have managed in the past to connect a dBase app to a mySQL
database over the web so I know it can be done. The original data being
written to the local database would now serve as a backup.



2. Is there a method of reading data from a dbf using an IP address????



Hope this all makes sense.



John
Lysander
2008-09-23 11:56:17 UTC
Permalink
Post by John Noble
My question is this - With as little work as possible, what would be the
best way for the main office to access the data held in other offices?
If the data structure used in the local offices is the same (same table
names, field structures and such...) then the most efficient way by far
is to use a terminal server in the HQ to run the applications. Also
makes updating an application very very easy.

dBase cooperates very nicely with terminal servers. Some issues if you
have been using personalized temp files, without personalizing the names
of the temp files. But that also can be seen to.

If the applications are different (for example localized versions) you
can still run them on the terminal server.
Post by John Noble
2. Is there a method of reading data from a dbf using an IP address????
If you WANT or MUST keep the applications and original data in the local
branches by all means, then duplicating each entry to a MySQL server is
a good alternative.

And, yes, if you are using BDE-Aliases to point to your data storage
folders dynamically, then this Alias can also be written in a form
"IP-Adress:\\FolderName".

Robert's suggestion is of course even better, but that would involve by
far more work than putting everything on one terminal server.
John Noble
2008-09-23 16:16:34 UTC
Permalink
Post by Lysander
And, yes, if you are using BDE-Aliases to point to your data storage
folders dynamically, then this Alias can also be written in a form
"IP-Adress:\\FolderName".
Are you saying that the BDE CAN point to dbf's on a remote machine using an IP address?

If so, could you elaborate on how it is done? I have previously only used the BDE for local tables.

John
Lysander
2008-09-23 16:32:53 UTC
Permalink
Post by John Noble
If so, could you elaborate on how it is done? I have previously only used the BDE for local tables.
go to your BDE-Administrator.
edit the Alias you want to use (or better create a new one).

use the notation: \\nnn.nnn.nnn.nnn\Path1\Path2\Database_Path

for example if you had the data aliased as "c:\data\dbase\customers"
you can now do "\\127.0.0.1\data\dBase\customers"


But..... WARNING!!! ....


it is _NOT_ a good idea to connect this way to remote servers unless you
have a very (I mean "very") fast, AND STABLE!!! internet connection.

DBFs over the internet are like a tank rolling through a glassware shop.
It is awfully slow and you have a fair chance that something will
seriously break.

Use an SQL-Server for the data, or use a Terminal Server for the
application.

Robert Bravery
2008-09-23 11:09:02 UTC
Permalink
HI John,

Probably the easiest way of doing this would be via a web interface with
some kind of security user management roles module.
You can connect via an ip address using a bde alias and with the right
configuration, but then you have huge security issues. (Depending on the
network and where the data is stored). Also you could have speed problem
because the data would have to be pulled down the line in order to be used.
With a web app, everything is don on the remote server, only the results are
passed down the line.

You have not mentioned whether this is on a private VPNor not.

Robert
Post by John Noble
Accessing dbf's Remotely.
The company which we have been asked to do this work for has several
offices. The main office(HQ) is in the UK while the others are in based
all over Europe.
Currently each office is responsible for producing its own invoices,
statements etc for their respective sales. Therefore, currently each
office writes to its own local database.
HQ will now be responsible for the producing of invoices on behalf of the
other offices.
My question is this - With as little work as possible, what would be the
best way for the main office to access the data held in other offices?
1. As well as the European offices writing to a local database (for
their own records), a duplicate entry is written to a mySQL database held
on a web server. This data could then be imported to the main office at
regular intervals. I have managed in the past to connect a dBase app to a
mySQL database over the web so I know it can be done. The original data
being written to the local database would now serve as a backup.
2. Is there a method of reading data from a dbf using an IP address????
Hope this all makes sense.
John
---
avast! Antivirus: Inbound message clean.
Virus Database (VPS): 080922-0, 22/09/2008
Tested on: 23/09/2008 01:03:55 PM
avast! - copyright (c) 1988-2008 ALWIL Software.
http://www.avast.com
--
Web Development, Hosting, Design and Content Management Systems
http://www.integralwebsolutions.co.za



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 080922-0, 22/09/2008
Tested on: 23/09/2008 01:09:03 PM
avast! - copyright (c) 1988-2008 ALWIL Software.
http://www.avast.com
Loading...