If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#62
|
|||
|
|||
On Sun, 06 Feb 2005 00:18:46 GMT, "David W. Fenton"
wrote: (Steve) wrote in : Why a backup program requires you to install MSDE is baffling. . . It's not to me -- it uses the MSDE to store its catalogs. I know, it was the backup program that requires it. . . . Our consultants installed the program on our file server, and I realized that now I have another service running on the box. Even if I had a seperate SQL Server box, I would still need this running. A simple link-list file would have been fine to keep tract of the file backup. I see no real problem with the concept of a backup program actually using a database to store its data. I like keeping things simple and stupid. I just don't see the data requirements of a backup program that requires the functionallity MSDE (SQL Server lite). There is no real concurrency issues, nor the need for triggers or stored procedures. It is not a client server system. Some of us don't want to run SQL Sever on our file server. Now maybe the backup program can be installed on a work station, but our outside consultants dumped it on the file server. It's Microsoft's implementation of the MSDE installers that is the problem. -- David W. Fenton http://www.bway.net/~dfenton dfenton at bway dot net http://www.bway.net/~dfassoc |
#63
|
|||
|
|||
(Steve) wrote in
: On Sun, 06 Feb 2005 00:18:46 GMT, "David W. Fenton" wrote: I see no real problem with the concept of a backup program actually using a database to store its data. I like keeping things simple and stupid. I just don't see the data requirements of a backup program that requires the functionallity MSDE (SQL Server lite). There is no real concurrency issues, nor the need for triggers or stored procedures. It is not a client server system. Some of us don't want to run SQL Sever on our file server. What database engine would you suggest? Seagate used to use Jet, with predictable conflicts with Access when installed on the same machine (not likely on a server, but I had the Seagate software installed on my workstation to run my backup tape). When the requirements for the db engine a 1. runs on all versions of Windows. 2. can be licensed for 3rd-party distribution. 3. is supported by a reliable company. your choices are pretty limited. The Veritas catalogs are *very* complex, as is necessitated by backing up NTFS volumes, where you have to store all sorts of information about the files, not just the filename, date and path. Second, the structure of the catalogs is by definition relational, so you *do* need a relational database. So, given those aspects, I don't see how Veritas could choose anything *other* than MSDE. The only question for me is why, if MS wants MSDE to be the answer for every company asking the 3 questions above, Microsoft doesn't do a better job of making MSDE install so that it doesn't step on other runtime installations. Now maybe the backup program can be installed on a work station, but our outside consultants dumped it on the file server. Backup programs belong on a server if they are backing up servers. Maybe you don't know too much about backup programs? -- David W. Fenton http://www.bway.net/~dfenton dfenton at bway dot net http://www.bway.net/~dfassoc |
#64
|
|||
|
|||
On Sun, 06 Feb 2005 23:44:11 GMT, "David W. Fenton"
wrote: (Steve) wrote in : On Sun, 06 Feb 2005 00:18:46 GMT, "David W. Fenton" wrote: I see no real problem with the concept of a backup program actually using a database to store its data. I like keeping things simple and stupid. I just don't see the data requirements of a backup program that requires the functionallity MSDE (SQL Server lite). There is no real concurrency issues, nor the need for triggers or stored procedures. It is not a client server system. Some of us don't want to run SQL Sever on our file server. What database engine would you suggest? Seagate used to use Jet, with predictable conflicts with Access when installed on the same machine (not likely on a server, but I had the Seagate software installed on my workstation to run my backup tape). When the requirements for the db engine a 1. runs on all versions of Windows. 2. can be licensed for 3rd-party distribution. 3. is supported by a reliable company. your choices are pretty limited. The Veritas catalogs are *very* complex, as is necessitated by backing up NTFS volumes, where you have to store all sorts of information about the files, not just the filename, date and path. Second, the structure of the catalogs is by definition relational, so you *do* need a relational database. So, given those aspects, I don't see how Veritas could choose anything *other* than MSDE. The only question for me is why, if MS wants MSDE to be the answer for every company asking the 3 questions above, Microsoft doesn't do a better job of making MSDE install so that it doesn't step on other runtime installations. Now maybe the backup program can be installed on a work station, but our outside consultants dumped it on the file server. Backup programs belong on a server if they are backing up servers. Maybe you don't know too much about backup programs? Well - jumping in here - to my mind, a stand-alone database server service is overkill for an application that has all components running on one machine. It also has many more installation issues than an in-process database engine like JET with DAO or ADO. With JET, there is the versioning issue, but there have been very fiew JET backward compatability problems that I've seen (except sp7). With MSDE, there's literally another server process that must be corectly installed, and must be started and stopped at the appropriate times, etc. I just can't see why MDSE is preferable to JET here. Even when complex data integrity rules apply, there's only one application using the data store, so the enforcement can simply be in a data access code layer, and need not be implemented as triggers, etc. In fact, IMO, triggers are much harder to write and maintain than data access layers. |
#65
|
|||
|
|||
On Sun, 06 Feb 2005 23:44:11 GMT, "David W. Fenton"
wrote: (Steve) wrote in : Now maybe the backup program can be installed on a work station, but our outside consultants dumped it on the file server. Backup programs belong on a server if they are backing up servers. Maybe you don't know too much about backup programs? -- Veritas is able to backup servers which it is not located on. Maybe you are using an older version? The rest of your post, though, was informative. Steven |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Running Spanish Access application into English version | Joseph | New Users | 0 | December 15th, 2004 10:15 AM |
Is MS Access XP Version compatible to Visual Basic 6 ? | rock72 | General Discussion | 2 | December 6th, 2004 06:42 PM |
is Access 2003 any better than XP? | Gorb | General Discussion | 4 | November 11th, 2004 09:44 PM |
is Access 2003 any better than XP? | Gorb | Using Forms | 2 | November 11th, 2004 09:20 AM |
Access XP Compared to Access 2003 | Mardene Leahu | New Users | 1 | October 1st, 2004 05:11 AM |