Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
VFP v SQL for large database applications
Message
From
20/04/2007 18:18:00
 
 
General information
Forum:
Visual FoxPro
Category:
Other
Environment versions
Visual FoxPro:
VFP 6 SP5
OS:
Windows XP SP2
Network:
Windows 2003 Server
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01218204
Message ID:
01218528
Views:
17
Conceptually speaking yes; I understand what you are saying.

What I actually (miss)understood when I was reading Alex post, was that MS backup wld simply get blocked/stopped when it 'smells' that some dbf file is open.

Unlike for mentioned conceptual problem (for 24/7/52 busy web app), what I was worried about, was simple real life situation when someone leave PS with app running open overnight, when MS backup is running.
But then again we wld notice backup interruption from backup logs.

Thks for clarifying.


>Hi, Srdjan.
>
>>>>However, I am able to copy entire database to local PC folder at any time
>>>>with all my users logged in.
>>>>Does it mean MS Backup is more demanding as to have exclusive grip
>>>>on data then ordinary copy call ?
>>>>
>>>>I am doing that from time when I need to troubleshot something on a snapshot of live data. Theoretically, that means that I could schedule (x)copying of entire set of folders to alternative location and then then perform backup from there even if my users were loged 24/7 ?
>>>
>>>Well, a DBF is a Windows file, not a real database. So if there is an Exclusive lock it is reflected in Windows OS, which may prevent a backup program for working with that file.
>>
>>That yes, but if someone uses optimistic table buffering troughout/without exceptions, then even MS backup might work or I am mistaken ?
>
>The problem with copying DBFs, even while it works, is that your backup has a great chance to be inconsistent. Say you have Orders and OrderItems tables, both around 300 Mb (just for the example). While you start copying the first table, people is still entering orders to the system, so when you start copying the second table you can have OrderItems which are not in the Orders table.
>
>This can be just a small annoyance if your are taking a snapshot to use as test data, but it is just plain wrong from a backup perspective. In case of a failure, if you restore this, you'll end up with a crippled data scenario.
>
>Now SQL Server perform backups in a totally different fashion because it holds all the transaction history, so when the backup starts is is taking a snapshot of this exact moment without taking ANY of the unfinished or later-started transactions from this moment on.
>
>See the big difference?
>
>Regards,
*****************
Srdjan Djordjevic
Limassol, Cyprus

Free Reporting Framework for VFP9 ;
www.Report-Sculptor.Com
Previous
Reply
Map
View

Click here to load this message in the networking platform