- Local time
- Today, 06:17
- Joined
- Feb 19, 2002
- Messages
- 46,883
Colin,
Please describe for me an application that needs to back up the data in the SQL Server database at a point in time. Just because you can do something doesn't mean that it is rational. We take backups of all databases frequently. Some get backed up multiple times per day. Not to preserve the data at a point in time but to safeguard against data loss and to make recovery quicker if you have to revert to a back up and forward apply updates. If you are creating database backups so you can do point in time reporting, you also need to coordinate with the FE version since random FE's can't be used against old backups. I'm guessing that this is a monolithic application where the data is embedded in the FE. Maybe you'd like to justify that for us also. I've seen a number of applications created by non-professionals that treat the app as a file. They enter the data for the month or year or whatever period and then the save the database and start the next period with an empty db. It's a way but of course it precludes easy period over period reporting and it opens up the situations where users corrupt the whole database by sharing the FE.
In a SQL Server environment, it is the DBA who is responsible for the care and management of the database. In an environment where Jet/ACE BE's are used, some more technical user is tasked with controlling the backups or a tool such as the one sold by FMS is used to schedule backups. Making a backup should never be left to an individual user
Please describe for me an application that needs to back up the data in the SQL Server database at a point in time. Just because you can do something doesn't mean that it is rational. We take backups of all databases frequently. Some get backed up multiple times per day. Not to preserve the data at a point in time but to safeguard against data loss and to make recovery quicker if you have to revert to a back up and forward apply updates. If you are creating database backups so you can do point in time reporting, you also need to coordinate with the FE version since random FE's can't be used against old backups. I'm guessing that this is a monolithic application where the data is embedded in the FE. Maybe you'd like to justify that for us also. I've seen a number of applications created by non-professionals that treat the app as a file. They enter the data for the month or year or whatever period and then the save the database and start the next period with an empty db. It's a way but of course it precludes easy period over period reporting and it opens up the situations where users corrupt the whole database by sharing the FE.
In a SQL Server environment, it is the DBA who is responsible for the care and management of the database. In an environment where Jet/ACE BE's are used, some more technical user is tasked with controlling the backups or a tool such as the one sold by FMS is used to schedule backups. Making a backup should never be left to an individual user
