Re: Where to keep the data?
- From: "Stefan Wuebbe" <stefan.wuebbe@xxxxxx>
- Date: Tue, 7 Jun 2005 21:00:45 +0200
1. Is it better for each installation to have its own local copy of the dbc
(I'm using only remote views, so far), or to keep the dbc shared on the file server? Keeping it local has some advantages, speed for one because it can be opened exclusive, plus I don't have to keep track of where the database is.
Yes, I think so too. As far as views-only.dbc's go, it's really a good idea to keep them locally.
OTOH, I already have another client-server application that shares the dbc on a file server, and it has worked pretty well so far. (In this case, I have to do it this way because there is shared data that I am not allowed to keep in the back end database). This approach does require that each workstation be set up with an ODBC source with the same name, so that the connection in the dbc can find it. Also, this makes installing new versions of the database much easier.
On the other hand, with a local remoteViews.dbc the maintenance thing can be even easier. You can for example ship the DBC with the EXE file by including its DB* files in memo fields, or generate a gendbc-like prg script at compile time and include that one, to create the rv.dbc on the fly at runtime later. I do so in some projects and did not see any disadvantages yet.
2. If I go with the shared-dbc-on-the-file-server approach, is there anything wrong with keeping "some" of the data in ordinary dbfs? Certain things, system preferences etc. don't need security or even special integrity, and are easier to browse and tweak if they're kept in a dbf.
No problem to have another sharedFiles.dbc somewhere on a LAN server, I'd say.
hth -Stefan
-- |\_/| ------ ProLib - programmers liberty ----------------- (.. ) Our MVPs and MCPs make the Fox run.... - / See us at www.prolib.de or www.AFPages.de -----------------------------------------------------------
"Paul Pedersen" <no-reply@xxxxxxxx> schrieb im Newsbeitrag news:u4kzF74aFHA.2536@xxxxxxxxxxxxxxxxxxxxxxx
I'm involved in migrating an existing multi-user application from FoxPro data on a file server to a SQL Server (MSDE actually) back end. The move is desired partly for security reasons (the application will handle money and accounts eventually), partly to make the data more accessible (with security provisions) to outside processes, and partly for data integrity concerns (the server is at some distance from the workstations, and there are occasional service outages due to hardware problems).
I have two questions.
1. Is it better for each installation to have its own local copy of the dbc (I'm using only remote views, so far), or to keep the dbc shared on the file server? Keeping it local has some advantages, speed for one because it can be opened exclusive, plus I don't have to keep track of where the database is.
OTOH, I already have another client-server application that shares the dbc on a file server, and it has worked pretty well so far. (In this case, I have to do it this way because there is shared data that I am not allowed to keep in the back end database). This approach does require that each workstation be set up with an ODBC source with the same name, so that the connection in the dbc can find it. Also, this makes installing new versions of the database much easier.
2. If I go with the shared-dbc-on-the-file-server approach, is there anything wrong with keeping "some" of the data in ordinary dbfs? Certain things, system preferences etc. don't need security or even special integrity, and are easier to browse and tweak if they're kept in a dbf.
Suggestions or insights will be much appreciated.
.
- References:
- Where to keep the data?
- From: Paul Pedersen
- Where to keep the data?
- Prev by Date: Re: Is there a nav bar for VFP?
- Next by Date: RE: Where to keep the data?
- Previous by thread: Where to keep the data?
- Next by thread: RE: Where to keep the data?
- Index(es):
Relevant Pages
|
