![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 6 of 6 total |
![]() |
Wed, Nov 18 2009 9:47 AM | Permanent Link |
John | Hi.
Is there any problem in using savetostream as a method for taking backup of tables? Thanks, John |
Wed, Nov 18 2009 10:45 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | John
Size? Why not use the built in backup routines? Roy Lambert [Team Elevate] |
Wed, Nov 18 2009 6:43 PM | Permanent Link |
"Raul" | It should be ok and i think the way dbisam 3.x backup was usually
implemented (other than just copying actual files). The major difference is that the built-in backup puts a read lock on all the table while with SaveToStream you need to process them one-by-one thus in theory increasing your chances of being inconsistent (if it's an issue for you). That being said the backup likely will be very quick unless you have very large tables so it might not matter to you. Also built-in backup takes care of putting all the tables into a single backup file and later allows you to query and restore from it while with savetostream you need to handle all of that. Raul "John" <eydunl@post.olivant.fo> wrote in message news:D9310DF0-5D79-4A38-9667-1C5F5A2F9360@news.elevatesoft.com... > Hi. > > Is there any problem in using savetostream as a method for taking backup > of tables? > > Thanks, > John > |
Wed, Nov 18 2009 7:03 PM | Permanent Link |
John | Roy, thanx for the reply.
Because the standard backup routines export to folder relative to server, while with savetostream it is possible to save to a folder on the client machine. -John Roy Lambert wrote: John Size? Why not use the built in backup routines? Roy Lambert [Team Elevate] |
Wed, Nov 18 2009 7:04 PM | Permanent Link |
John | Raul, thanx for the info!
"Raul" wrote: It should be ok and i think the way dbisam 3.x backup was usually implemented (other than just copying actual files). The major difference is that the built-in backup puts a read lock on all the table while with SaveToStream you need to process them one-by-one thus in theory increasing your chances of being inconsistent (if it's an issue for you). That being said the backup likely will be very quick unless you have very large tables so it might not matter to you. Also built-in backup takes care of putting all the tables into a single backup file and later allows you to query and restore from it while with savetostream you need to handle all of that. Raul "John" <eydunl@post.olivant.fo> wrote in message news:D9310DF0-5D79-4A38-9667-1C5F5A2F9360@news.elevatesoft.com... > Hi. > > Is there any problem in using savetostream as a method for taking backup > of tables? > > Thanks, > John > |
Thu, Nov 19 2009 1:44 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | John,
<< Because the standard backup routines export to folder relative to server, while with savetostream it is possible to save to a folder on the client machine. >> Don't use SaveToStream for backups. It works entirely in memory, and therefore is very limited in terms of the size of the tables that it can effectively work with. If you need to transmit a file from the server to a client, use a server-side procedure to transmit a backup file back to the client. Just backup the file to a pre-designated location on the server, and then have the client request the backup from the server with the server-side procedure. You can find an example of this type of file transmittal here: http://www.elevatesoft.com/manual?action=mantopic&id=dbisam4&product=d&version=7&category=1&topic=8 under "Server Procedures". -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |