Re: Creating a copy of a database -- best practice?
On 2019-03-04 17:52, Fletcher Johnson wrote: Mike, I am assuming that the backup has to happen while the tables are in use (or you would just copy over the data folder via windows.) \ Creating the DBC programmatically should be easy (I seem to remember there is an option in VFP that generates the code to do so - which includes all the rules, RI, structures, etc. ) Just no data. You could use this to create a destination with no data and then append the source data to the empty backup tables. This would create a very clean, packed, set of data. Of course, it's not that simple if anyone is using it at the time. You probably want to lock the source tables (and related) before appending. Or if you have a last modified record in the tables, use that to check for any changes since the data was copied. Or you might use cursors/views so that changes made by others don't affect you while copying. In fact, if you use a view or have buffering on, once the append is complete, you can check for changes. Anyway, I am sure you will find something that works best for you, Yeah, needs to happen while folks are still in it. I think GENDBC was the utility you were thinking of. This is all a moot point though; I'm gonna recommend Frank Perez and Rick Schummer's CleverFox Backup. It's the bomb. ;-) ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/c0c28941de25379e6f996ed2a0974...@mbsoftwaresolutions.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
RE: Creating a copy of a database -- best practice?
Mike,
I am assuming that the backup has to happen while the tables are in use (or
you would just copy over the data folder via windows.)
\
Creating the DBC programmatically should be easy (I seem to remember there
is an option in VFP that generates the code to do so - which includes all
the rules, RI, structures, etc. ) Just no data. You could use this to
create a destination with no data and then append the source data to the
empty backup tables.
This would create a very clean, packed, set of data.
Of course, it's not that simple if anyone is using it at the time.
You probably want to lock the source tables (and related) before appending.
Or if you have a last modified record in the tables, use that to check for
any changes since the data was copied. Or you might use cursors/views so
that changes made by others don't affect you while copying. In fact, if you
use a view or have buffering on, once the append is complete, you can check
for changes.
Anyway, I am sure you will find something that works best for you,
Fletcher
Fletcher Johnson
fletchersjohn...@yahoo.com
LinkedIn.com/in/FletcherJohnson
twitter.com/fletcherJ
strava.com/athletes/fletcherjohnson
408-946-0960 - work
408-781-2345 - cell
-Original Message-
From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of
mbsoftwaresoluti...@mbsoftwaresolutions.com
Sent: Wednesday, February 27, 2019 9:23 AM
To: ProFox
Subject: Creating a copy of a database -- best practice?
I can easily do something like this:
CREATE DATABASE C:\Backup\MyDBC.dbc
OPEN DATABASE C:\Production\MyDBC.dbc
liNumTables = adbobjects(laTables,'TABLE')
for ii = 1 to liNumTables
lcFile = forceext("C:\BACKUP\" + laTables[ii],'dbf')
use laTables[ii]
copy to (lcFile) database C:\Backup\MyDBC.dbc with cdx
use
endfor
..and that would get me a copy of all of the tables with their indexes.
Great. But what's the easiest way to get all of the DBC meta-data into
that new Backup database copy? I can't USE the MyDBC.dbc and do a COPY
TO as that only makes the result a DBF and FPT.
Trying to think about a good disaster recovery plan (besides using
CleverFox from Rick Schummer and Frank Perez...which is probably the
best option!) for automating backups at the client who just got that
ransomware virus.
tia,
--Mike
[excessive quoting removed by server]
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/043701d4d2dd$02e16bc0$08a44340$@yahoo.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
Re: Creating a copy of a database -- best practice? - checking email - did not come through before
Below is a function to backup a database from a source folder to a
target folder, including all triggers, stored procedures, default field
values etc. I do not think there was anything wrong with the original
"table" copying code that Mike had, but I did not have that email handy
when I did this. So just be advised if there was something special in
that original code, my code below may not handle it, etc. This code
should work even if the source database is open as well as tables in
that database being open by another application. Of course, the DB and
tables are expected to be open in SHARED mode (aka, non-EXCLUSIVE). Also
note that if this code is placed directly in an application, it will
close all databases/tables. So if the application needs to have this
function, some "environmental saving/restore" code would need to be
added (pretty simple to do with the AUSED() function, etc).
This uses my "Option 3" method from the earlier email. Essentially,
after all the base data is copied, a direct "file copy" on the DBC data
is performed. Technically, COPY FILE ... could probably be used for all
files of the DB, but by using the table "COPY" (not COPY FILE) it
drastically reduces any potential for 'corruption' due to multi-user
actions, etc. And, using COPY FILE only on the "database container"
files is quite reasonably safe since DATABASE LEVEL modifications are
generally not a "user" operation and so could be avoided during the
backup process.
It goes without saying, before using in production, this code should be
thoroughly tested, customized, etc.
HTH,
-Charlie
PS. Please don't make fun of my variable names - I was in a hurry when I
gen'd this up (hahahaha)
*--
FUNCTION db_backup
*-- purpose: create a backup copy of a VFP database, including all
*-- stored procedures, triggers, etc
*-- Parameters:
*-- from_db: full path qualified (x:\sample\one\dbname)
*-- to_db: full path qualified
*--
*-- Assupmtions:
*-- - this code is mainly 'proof of concept' code, so several
*-- sections should be checked before production use
*-- - the target db (to_db) is not OPEN by any application
PARAMETERS from_db, to_db
LOCAL target_dir, ntbls, ctbl, cdbname, from_dir
*-- should "harden" this code before production - e.g. ensure source
*-- db exists, decide and code what should be done if destination db
*-- already exists (only want one db in the backup folder, etc)
*-- Warning! Exclusive being off is pretty much required for this
*-- code. If your other code needs Exclusive ON, change code to
*-- turn it back on in the end of this function.
SET EXCLUSIVE OFF
*-- Warning! the following block deletes any VFP database files in
*-- the target folder. So this needs to be changed if that folder
*-- is being used to backup other DBs, free tables, etc.
target_dir = ADDBS(JUSTPATH(to_db))
DELETE FILE (target_dir + "*.db?")
DELETE FILE (target_dir + "*.dct")
DELETE FILE (target_dir + "*.dcx")
DELETE FILE (target_dir + "*.cdx")
DELETE FILE (target_dir + "*.fpt")
*-- Create the target database and copy all the base table data
CREATE DATABASE (to_db)
OPEN DATABASE (from_db)
ntbls = ADBOBJECTS(_atbls, 'TABLE')
FOR ni = 1 TO ntbls
ctbl = ALLTRIM(_atbls[ni])
*-- if the table being copied is opened elsewhere in the app
*-- need to use it 'again'
IF USED(ctbl)
USE (ctbl) AGAIN IN 0 ALIAS TMPCOPY
ELSE
USE (ctbl) IN 0 ALIAS TMPCOPY
ENDIF
SELECT TMPCOPY
COPY TO (target_dir + ctbl) DATABASE (to_db) WITH cdx
USE IN ("TMPCOPY")
ENDFOR
*-- now, to get all stored procs, etc, need to copy the dbc. Test
*-- this code thoroughly
CLOSE DATABASES all
*-- this assumes the backup db should have the same name as the
*-- source db. If there is a desire to rename the backup db,
*-- this code should be changed to grab the target name from
*-- the to_db parameter
cdbname = JUSTSTEM(from_db)
from_dir = ADDBS(JUSTPATH(from_db))
*-- NOTE: turning SAFETY off to avoid pop-up warning
SET SAFETY OFF
COPY FILE (from_dir + cdbname + ".dbc") to ;
(target_dir + cdbname + ".dbc")
COPY FILE (from_dir + cdbname + ".dcx") to ;
(target_dir + cdbname + ".dcx")
COPY FILE (from_dir + cdbname + ".dct") to ;
(target_dir + cdbname + ".dct")
SET SAFETY ON
*-- this might not be necessary, but including it for
*-- conceptual consideration
COMPILE DATABASE (to_db)
OPEN DATABASE (to_db) EXCLUSIVE
VALIDATE DATABASE
CLOSE DATABASE
RETURN
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/fa585f8a-89d2-13a4-f3a8-718d3a0e4...@gmail.com
** All postings, unless explicitly stated otherwise, are
RE: Creating a copy of a database -- best practice?
Snap
-Original Message-
From: ProfoxTech On Behalf Of Dave Crozier
Sent: 01 March 2019 09:47
To: profoxt...@leafe.com
Subject: RE: Creating a copy of a database -- best practice?
Sent by an external sender
--
Part timers all of you... 66 this year!!
Dave Crozier
Software Development Manager
Flexipol Packaging Ltd.
﴾⚆ᨎ⚆﴿
Flexipol® Packaging Ltd
T 01706 222 792
E dcroz...@flexipol.co.uk
W https://www.flexipol.co.uk/
Follow us:
Unit 14 Bentwood Road, Carrs Industrial Estate, Haslingden, Lancashire, BB4 5HH
This communication and the information it contains is intended for the person
or organisation to whom it is addressed. Its contents are confidential and may
be protected in law. If you have received this e-mail in error you must not
copy, distribute or take any action in reliance on it. Unauthorised use,
copying or disclosure of any of it may be unlawful. If you have received this
message in error, please notify us immediately by telephone or email.
Flexipol Packaging Ltd. has taken every reasonable precaution to minimise the
risk of virus transmission through email and therefore any files sent via
e-mail will have been checked for known viruses. However, you are advised to
run your own virus check before opening any attachments received as Flexipol
Packaging Ltd will not in any event accept any liability whatsoever once an
e-mail and/or any attachment is received.
It is the responsibility of the recipient to ensure that they have adequate
virus protection.
-
Terms & Conditions:
Notwithstanding delivery and the passing of risk in the goods, the property in
the goods shall not pass to the buyer until the seller Flexipol Packaging Ltd.
("The Company") has received in cash or cleared funds payment in full of the
price of the goods and all other goods agreed to be sold by the seller to the
buyer for which payment is then due. Until such time as the property in the
goods passes to the buyer, the buyer shall hold the goods as the seller's
fiduciary agent and bailee and keep the goods separate from those of the buyer
and third parties and properly stored protected and insured and identified as
the seller's property but shall be entitled to resell or use the goods in the
ordinary course of its business. Until such time as the property in the goods
passes to the buyer the seller shall be entitled at any time -Original
Message-
From: ProFox On Behalf Of John Weller
Sent: 01 March 2019 09:20
To: profox@leafe.com
Subject: RE: Creating a copy of a database -- best practice?
A mere youth and stripling
John Weller
01380 723235
07976 393631
Turning 60 this year. :)
[excessive quoting removed by server]
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/lo2p265mb086305dfb7f6cb6bc46f4e5bfb...@lo2p265mb0863.gbrp265.prod.outlook.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
Report [OT] Abuse:
http://leafe.com/reportAbuse/lo2p265mb086305dfb7f6cb6bc46f4e5bfb...@lo2p265mb0863.gbrp265.prod.outlook.com
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/byapr02mb58785d242fd68e0d967b93e7a1...@byapr02mb5878.namprd02.prod.outlook.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
Re: Creating a copy of a database -- best practice? - checking email - did not come through before
On 2019-03-02 08:14, Charlie-gm wrote:
Ok, I haven't done this in a while, but I think I have done this a few
ways.
First, by "metadata" of the database, I assume you mean stored
procedures, maybe table triggers, database comment field?
I'll also assume you are trying to run from within an .exe (so
commands like COPY PROCEDURES TO... and APPEND PROCEDURES FROM ...
will not be available)
So...
1) if you know the "data model" of the dbc, you can open it like a
table - then look for the metadata items you want (the stored
procedure code, trigger code, etc). Do a SCATTER MEMO NAME ... Then
open the other DBC as a table and do an APPEND FROM NAME ... After
everything is copied that way I think you will want to do a PACK
DATABASE or maybe VALIDATE DATABASE on the backup. I seem to recall
doing that.
2) after you've copied all the tables, copy the "database files" with
"COPY FILE TO " - copy the dbc, dct, and dcx this way.
Again a PACK or VALIDATE database may be needed afterwards. And of
course, be careful with this, test it out, etc. But I definitely used
this approach before.
3) if you are not worried about the tables being opened at the time of
doing the backup, you could just do the "COPY FILE TO "
- that command allows paths in the from/to. Also, I think it allows
wildcards, so you could do a complete copy in 1 command. Of course,
the downside is the assumption of files being closed.
Hi Charlie,
I've got VFP available so COPY/APPEND PROCEDURES is available. So I
wrote a quick PRG and got the stored procedures just fine with
that...but the part that's missing now is the table-specific data like
default values (important as some call the usual newid('table') function
in the default PK field) and captions (not important).
--Mike
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/e6efbd4226dee2145628baff4f262...@mbsoftwaresolutions.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
Creating a copy of a database -- best practice? - checking email - did not come through before
Ok, I haven't done this in a while, but I think I have done this a few
ways.
First, by "metadata" of the database, I assume you mean stored
procedures, maybe table triggers, database comment field?
I'll also assume you are trying to run from within an .exe (so commands
like COPY PROCEDURES TO... and APPEND PROCEDURES FROM ... will not be
available)
So...
1) if you know the "data model" of the dbc, you can open it like a table
- then look for the metadata items you want (the stored procedure code,
trigger code, etc). Do a SCATTER MEMO NAME ... Then open the other DBC
as a table and do an APPEND FROM NAME ... After everything is copied
that way I think you will want to do a PACK DATABASE or maybe VALIDATE
DATABASE on the backup. I seem to recall doing that.
2) after you've copied all the tables, copy the "database files" with
"COPY FILE TO " - copy the dbc, dct, and dcx this way.
Again a PACK or VALIDATE database may be needed afterwards. And of
course, be careful with this, test it out, etc. But I definitely used
this approach before.
3) if you are not worried about the tables being opened at the time of
doing the backup, you could just do the "COPY FILE TO " -
that command allows paths in the from/to. Also, I think it allows
wildcards, so you could do a complete copy in 1 command. Of course, the
downside is the assumption of files being closed.
-HTH,
-Charlie
-
On 2/27/2019 12:22 PM, mbsoftwaresoluti...@mbsoftwaresolutions.com wrote:
I can easily do something like this:
CREATE DATABASE C:\Backup\MyDBC.dbc
OPEN DATABASE C:\Production\MyDBC.dbc
liNumTables = adbobjects(laTables,'TABLE')
for ii = 1 to liNumTables
lcFile = forceext("C:\BACKUP\" + laTables[ii],'dbf')
use laTables[ii]
copy to (lcFile) database C:\Backup\MyDBC.dbc with cdx
use
endfor
...and that would get me a copy of all of the tables with their indexes.
Great. But what's the easiest way to get all of the DBC meta-data
into that new Backup database copy? I can't USE the MyDBC.dbc and do a
COPY TO as that only makes the result a DBF and FPT.
Trying to think about a good disaster recovery plan (besides using
CleverFox from Rick Schummer and Frank Perez...which is probably the
best option!) for automating backups at the client who just got that
ransomware virus.
tia,
--Mike
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/9309004b-cd50-9d5a-70b8-ef16fd0b5...@gmail.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
RE: Creating a copy of a database -- best practice?
At 14:49 2019-02-28, "Tracy Pearson" wrote: I feel like the young pup still being just 52. I used to define "old" as being five or more years older than I was. This was when I was a lot younger (kid and young adult), and it made sense then. I am 58 and hardly pay attention to it now. You are still a young pup though. Oops! [snip] Sincerely, Gene Wirchenko ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/16085a74800ff8e7b4ba4665cce61182@mtlp86 ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Creating a copy of a database -- best practice?
On 2019-03-01 05:08, Peter Cushing wrote: Hi Mike, Your COPY TO won't give you all the meta data, which is what you wanted in the first place. When you already have a copy of the system the meta data is already there, you are just updating the data. HTH Peter Cushing IT Department WHISPERING SMITH Ah yes...thanks! ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/551028cdf37d7838feb9ceb2c5c0b...@mbsoftwaresolutions.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Creating a copy of a database -- best practice?
Hi Mike,
Your COPY TO won't give you all the meta data, which is what you wanted
in the first place. When you already have a copy of the system the meta
data is already there, you are just updating the data.
HTH
Peter Cushing
IT Department
WHISPERING SMITH
On 28/02/2019 21:37, mbsoftwaresoluti...@mbsoftwaresolutions.com wrote:
> On 2019-02-28 04:43, Peter Cushing wrote:
>> On 27/02/2019 17:22, mbsoftwaresoluti...@mbsoftwaresolutions.com wrote:
>>> I can easily do something like this:
>>>
>>> CREATE DATABASE C:\Backup\MyDBC.dbc
>>> OPEN DATABASE C:\Production\MyDBC.dbc
>>> liNumTables = adbobjects(laTables,'TABLE')
>>> for ii = 1 to liNumTables
>>>lcFile = forceext("C:\BACKUP\" + laTables[ii],'dbf')
>>>use laTables[ii]
>>>copy to (lcFile) database C:\Backup\MyDBC.dbc with cdx
>>>use
>>> endfor
>>>
>>>
>>> ...and that would get me a copy of all of the tables with their
>>> indexes.
>>> Great. But what's the easiest way to get all of the DBC meta-data
>>> into
>>> that new Backup database copy? I can't USE the MyDBC.dbc and do a
>>> COPY
>>> TO as that only makes the result a DBF and FPT.
>>>
>> An easy way to get a copy of the data is to have a copy of all the data
>> in another folder, then using your loop above, zap each table and
>> append
>> from the live data. We use it here as a rough and ready backup during
>> the day, while people are in the system. Your copy then has all the
>> same meta data as the original.
>
> Hi Peter,
>
> I see no difference between my COPY TO versus
> doing an APPEND FROM from my backup table. ???
>
> Am I mistaken?
>
> tia,
> --Mike
>
[excessive quoting removed by server]
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/2903f705-93ff-59d4-a619-59b556e2b...@whisperingsmith.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
RE: Creating a copy of a database -- best practice?
66 her in June... I suddenly feel very OLD!!!
Back in the day when Foxbase was on 720k floppy disks..
Dave Crozier
Software Development Manager
Flexipol Packaging Ltd.
﴾⚆ᨎ⚆﴿
Flexipol® Packaging Ltd
T 01706 222 792
E dcroz...@flexipol.co.uk
W https://www.flexipol.co.uk/
Follow us:
Unit 14 Bentwood Road, Carrs Industrial Estate, Haslingden, Lancashire, BB4 5HH
This communication and the information it contains is intended for the person
or organisation to whom it is addressed. Its contents are confidential and may
be protected in law. If you have received this e-mail in error you must not
copy, distribute or take any action in reliance on it. Unauthorised use,
copying or disclosure of any of it may be unlawful. If you have received this
message in error, please notify us immediately by telephone or email.
Flexipol Packaging Ltd. has taken every reasonable precaution to minimise the
risk of virus transmission through email and therefore any files sent via
e-mail will have been checked for known viruses. However, you are advised to
run your own virus check before opening any attachments received as Flexipol
Packaging Ltd will not in any event accept any liability whatsoever once an
e-mail and/or any attachment is received.
It is the responsibility of the recipient to ensure that they have adequate
virus protection.
-
Terms & Conditions:
Notwithstanding delivery and the passing of risk in the goods, the property in
the goods shall not pass to the buyer until the seller Flexipol Packaging Ltd.
("The Company") has received in cash or cleared funds payment in full of the
price of the goods and all other goods agreed to be sold by the seller to the
buyer for which payment is then due. Until such time as the property in the
goods passes to the buyer, the buyer shall hold the goods as the seller's
fiduciary agent and bailee and keep the goods separate from those of the buyer
and third parties and properly stored protected and insured and identified as
the seller's property but shall be entitled to resell or use the goods in the
ordinary course of its business. Until such time as the property in the goods
passes to the buyer the seller shall be entitled at any time
-Original Message-
From: ProFox On Behalf Of John Weller
Sent: 01 March 2019 09:20
To: profox@leafe.com
Subject: RE: Creating a copy of a database -- best practice?
A mere youth and stripling
John Weller
01380 723235
07976 393631
Turning 60 this year. :)
[excessive quoting removed by server]
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/lo2p265mb0863eb15dfb10164169dfdfbfb...@lo2p265mb0863.gbrp265.prod.outlook.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
RE: Creating a copy of a database -- best practice?
Part timers all of you... 66 this year!!
Dave Crozier
Software Development Manager
Flexipol Packaging Ltd.
﴾⚆ᨎ⚆﴿
Flexipol® Packaging Ltd
T 01706 222 792
E dcroz...@flexipol.co.uk
W https://www.flexipol.co.uk/
Follow us:
Unit 14 Bentwood Road, Carrs Industrial Estate, Haslingden, Lancashire, BB4 5HH
This communication and the information it contains is intended for the person
or organisation to whom it is addressed. Its contents are confidential and may
be protected in law. If you have received this e-mail in error you must not
copy, distribute or take any action in reliance on it. Unauthorised use,
copying or disclosure of any of it may be unlawful. If you have received this
message in error, please notify us immediately by telephone or email.
Flexipol Packaging Ltd. has taken every reasonable precaution to minimise the
risk of virus transmission through email and therefore any files sent via
e-mail will have been checked for known viruses. However, you are advised to
run your own virus check before opening any attachments received as Flexipol
Packaging Ltd will not in any event accept any liability whatsoever once an
e-mail and/or any attachment is received.
It is the responsibility of the recipient to ensure that they have adequate
virus protection.
-
Terms & Conditions:
Notwithstanding delivery and the passing of risk in the goods, the property in
the goods shall not pass to the buyer until the seller Flexipol Packaging Ltd.
("The Company") has received in cash or cleared funds payment in full of the
price of the goods and all other goods agreed to be sold by the seller to the
buyer for which payment is then due. Until such time as the property in the
goods passes to the buyer, the buyer shall hold the goods as the seller's
fiduciary agent and bailee and keep the goods separate from those of the buyer
and third parties and properly stored protected and insured and identified as
the seller's property but shall be entitled to resell or use the goods in the
ordinary course of its business. Until such time as the property in the goods
passes to the buyer the seller shall be entitled at any time
-Original Message-
From: ProFox On Behalf Of John Weller
Sent: 01 March 2019 09:20
To: profox@leafe.com
Subject: RE: Creating a copy of a database -- best practice?
A mere youth and stripling
John Weller
01380 723235
07976 393631
Turning 60 this year. :)
[excessive quoting removed by server]
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/lo2p265mb086305dfb7f6cb6bc46f4e5bfb...@lo2p265mb0863.gbrp265.prod.outlook.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
RE: Creating a copy of a database -- best practice?
A mere youth and stripling John Weller 01380 723235 07976 393631 Turning 60 this year. :) ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/005001d4d00f$e7fa3b90$b7eeb2b0$@johnweller.co.uk ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
RE: Creating a copy of a database -- best practice?
I feel like the young pup still being just 52. -Original Message- From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Stephen Russell Sent: Thursday, February 28, 2019 5:46 PM To: profoxt...@leafe.com Subject: Re: Creating a copy of a database -- best practice? Turning 60 this year. :) On Thu, Feb 28, 2019 at 4:33 PM Tracy Pearson wrote: > You'll have trouble the same way if a user is saving the Word or Excel > file. > Writing to tables locks a portion of the table, and sometimes all of the > table which can cause copy failures.. > You've been out of the VFP for a couple of years and haven't worked with > DBFs for longer. > We'll forgive your older age and forgetfulness. > > Tracy > > -Original Message- > From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of > Stephen > Russell > Sent: Thursday, February 28, 2019 5:29 PM > To: profoxt...@leafe.com > Subject: Re: Creating a copy of a database -- best practice? > > Would the table or index not be included? I get backups of word and excel > files if they are open. > > > > > > On Thu, Feb 28, 2019 at 3:40 PM > > wrote: > > > On 2019-02-28 07:08, Stephen Russell wrote: > > > Why not make a compressed file of the entire folder where the data > > > lies? > > > After file is created move it to a different machine off the network. > > > > > > Because I think open DBFs would present a problem with that approach??? > > [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/000f01d4cfb7$cbf8c4f0$63ea4ed0$@powerchurch.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Creating a copy of a database -- best practice?
Turning 60 this year. :) On Thu, Feb 28, 2019 at 4:33 PM Tracy Pearson wrote: > You'll have trouble the same way if a user is saving the Word or Excel > file. > Writing to tables locks a portion of the table, and sometimes all of the > table which can cause copy failures.. > You've been out of the VFP for a couple of years and haven't worked with > DBFs for longer. > We'll forgive your older age and forgetfulness. > > Tracy > > -Original Message- > From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of > Stephen > Russell > Sent: Thursday, February 28, 2019 5:29 PM > To: profoxt...@leafe.com > Subject: Re: Creating a copy of a database -- best practice? > > Would the table or index not be included? I get backups of word and excel > files if they are open. > > > > > > On Thu, Feb 28, 2019 at 3:40 PM > > wrote: > > > On 2019-02-28 07:08, Stephen Russell wrote: > > > Why not make a compressed file of the entire folder where the data > > > lies? > > > After file is created move it to a different machine off the network. > > > > > > Because I think open DBFs would present a problem with that approach??? > > [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cajidmylslflrkmv1zvo1eat8gtj9-bbodbtehwbixyvorxq...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
RE: Creating a copy of a database -- best practice?
You'll have trouble the same way if a user is saving the Word or Excel file. Writing to tables locks a portion of the table, and sometimes all of the table which can cause copy failures.. You've been out of the VFP for a couple of years and haven't worked with DBFs for longer. We'll forgive your older age and forgetfulness. Tracy -Original Message- From: ProfoxTech [mailto:profoxtech-boun...@leafe.com] On Behalf Of Stephen Russell Sent: Thursday, February 28, 2019 5:29 PM To: profoxt...@leafe.com Subject: Re: Creating a copy of a database -- best practice? Would the table or index not be included? I get backups of word and excel files if they are open. On Thu, Feb 28, 2019 at 3:40 PM wrote: > On 2019-02-28 07:08, Stephen Russell wrote: > > Why not make a compressed file of the entire folder where the data > > lies? > > After file is created move it to a different machine off the network. > > > Because I think open DBFs would present a problem with that approach??? > [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/000d01d4cfb5$9869ae80$c93d0b80$@powerchurch.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Creating a copy of a database -- best practice?
Would the table or index not be included? I get backups of word and excel files if they are open. On Thu, Feb 28, 2019 at 3:40 PM wrote: > On 2019-02-28 07:08, Stephen Russell wrote: > > Why not make a compressed file of the entire folder where the data > > lies? > > After file is created move it to a different machine off the network. > > > Because I think open DBFs would present a problem with that approach??? > [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CAJidMY+TOxSCXKWE=gd3sw8gkvcklnhy8enm47v5assexrt...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Creating a copy of a database -- best practice?
On 2019-02-28 07:08, Stephen Russell wrote: Why not make a compressed file of the entire folder where the data lies? After file is created move it to a different machine off the network. Because I think open DBFs would present a problem with that approach??? ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/d75f9d1d4ae9647483d5aeb68ad52...@mbsoftwaresolutions.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Creating a copy of a database -- best practice?
On 2019-02-28 04:43, Peter Cushing wrote:
On 27/02/2019 17:22, mbsoftwaresoluti...@mbsoftwaresolutions.com wrote:
I can easily do something like this:
CREATE DATABASE C:\Backup\MyDBC.dbc
OPEN DATABASE C:\Production\MyDBC.dbc
liNumTables = adbobjects(laTables,'TABLE')
for ii = 1 to liNumTables
lcFile = forceext("C:\BACKUP\" + laTables[ii],'dbf')
use laTables[ii]
copy to (lcFile) database C:\Backup\MyDBC.dbc with cdx
use
endfor
...and that would get me a copy of all of the tables with their
indexes.
Great. But what's the easiest way to get all of the DBC meta-data
into
that new Backup database copy? I can't USE the MyDBC.dbc and do a
COPY
TO as that only makes the result a DBF and FPT.
An easy way to get a copy of the data is to have a copy of all the data
in another folder, then using your loop above, zap each table and
append
from the live data. We use it here as a rough and ready backup during
the day, while people are in the system. Your copy then has all the
same meta data as the original.
Hi Peter,
I see no difference between my COPY TO versus
doing an APPEND FROM from my backup table. ???
Am I mistaken?
tia,
--Mike
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/57548c2cb0741015511f60d8bcfd5...@mbsoftwaresolutions.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
Re: Creating a copy of a database -- best practice?
Why not make a compressed file of the entire folder where the data lies? After file is created move it to a different machine off the network. On Thu, Feb 28, 2019 at 4:17 AM Alan Bourke wrote: > Copy and rename all the data and database container files. > > For each DBF in the copied and renamed data, update the backlink so that > it points at your copied and renamed DBC. > Open the copied and renamed DBC as a table, and update the metadata > describing the tables to reflect their new names. > > This is discussed here: > > http://www.ml-consult.co.uk/foxst-47.htm > > > -- > Alan Bourke > alanpbourke (at) fastmail (dot) fm > [excessive quoting removed by server] ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cajidmy+4ekpeqrf0p4z6u6pixx7oghyqkkdwypz5pzb1w3v...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Creating a copy of a database -- best practice?
Copy and rename all the data and database container files. For each DBF in the copied and renamed data, update the backlink so that it points at your copied and renamed DBC. Open the copied and renamed DBC as a table, and update the metadata describing the tables to reflect their new names. This is discussed here: http://www.ml-consult.co.uk/foxst-47.htm -- Alan Bourke alanpbourke (at) fastmail (dot) fm ___ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cebc2b5e-003a-4c60-a708-dbc46f11b...@www.fastmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
Re: Creating a copy of a database -- best practice?
On 27/02/2019 17:22, mbsoftwaresoluti...@mbsoftwaresolutions.com wrote:
> I can easily do something like this:
>
> CREATE DATABASE C:\Backup\MyDBC.dbc
> OPEN DATABASE C:\Production\MyDBC.dbc
> liNumTables = adbobjects(laTables,'TABLE')
> for ii = 1 to liNumTables
>lcFile = forceext("C:\BACKUP\" + laTables[ii],'dbf')
>use laTables[ii]
>copy to (lcFile) database C:\Backup\MyDBC.dbc with cdx
>use
> endfor
>
>
> ...and that would get me a copy of all of the tables with their indexes.
> Great. But what's the easiest way to get all of the DBC meta-data into
> that new Backup database copy? I can't USE the MyDBC.dbc and do a COPY
> TO as that only makes the result a DBF and FPT.
>
An easy way to get a copy of the data is to have a copy of all the data
in another folder, then using your loop above, zap each table and append
from the live data. We use it here as a rough and ready backup during
the day, while people are in the system. Your copy then has all the
same meta data as the original.
Peter
This communication is intended for the person or organisation to whom it is
addressed. The contents are confidential and may be protected in law.
Unauthorised use, copying or disclosure of any of it may be unlawful. If you
have received this message in error, please notify us immediately by telephone
or email.
www.whisperingsmith.com
Whispering Smith Ltd Head Office:61 Great Ducie Street, Manchester M3 1RR.
Tel:0161 831 3700
Fax:0161 831 3715
London Office: 101 St. Martin's Lane,London, WC2N 4AZ Tel:0207 299 7960
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/ceec749d-28b9-1502-45bd-6796cdf6a...@whisperingsmith.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
Re: Creating a copy of a database -- best practice?
Ok, I haven't done this in a while, but I think I have done this a few ways.
First, by "metadata" of the database, I assume you mean stored
procedures, maybe table triggers, database comment field?
I'll also assume you are trying to run from within an .exe (so commands
like COPY PROCEDURES TO... and APPEND PROCEDURES FROM ... will not be
available)
So...
1) if you know the "data model" of the dbc, you can open it like a table
- then look for the metadata items you want (the stored procedure code,
trigger code, etc). Do a SCATTER MEMO NAME ... Then open the other DBC
as a table and do an APPEND FROM NAME ... After everything is copied
that way I think you will want to do a PACK DATABASE or maybe VALIDATE
DATABASE on the backup. I seem to recall doing that.
2) after you've copied all the tables, copy the "database files" with
"COPY FILE TO " - copy the dbc, dct, and dcx this way.
Again a PACK or VALIDATE database may be needed afterwards. And of
course, be careful with this, test it out, etc. But I definitely used
this approach before.
3) if you are not worried about the tables being opened at the time of
doing the backup, you could just do the "COPY FILE TO " -
that command allows paths in the from/to. Also, I think it allows
wildcards, so you could do a complete copy in 1 command. Of course, the
downside is the assumption of files being closed.
-HTH,
-Charlie
On 2/27/2019 12:22 PM, mbsoftwaresoluti...@mbsoftwaresolutions.com wrote:
I can easily do something like this:
CREATE DATABASE C:\Backup\MyDBC.dbc
OPEN DATABASE C:\Production\MyDBC.dbc
liNumTables = adbobjects(laTables,'TABLE')
for ii = 1 to liNumTables
lcFile = forceext("C:\BACKUP\" + laTables[ii],'dbf')
use laTables[ii]
copy to (lcFile) database C:\Backup\MyDBC.dbc with cdx
use
endfor
...and that would get me a copy of all of the tables with their
indexes. Great. But what's the easiest way to get all of the DBC
meta-data into that new Backup database copy? I can't USE the
MyDBC.dbc and do a COPY TO as that only makes the result a DBF and FPT.
Trying to think about a good disaster recovery plan (besides using
CleverFox from Rick Schummer and Frank Perez...which is probably the
best option!) for automating backups at the client who just got that
ransomware virus.
tia,
--Mike
[excessive quoting removed by server]
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/ff594e8b-a5da-3f8d-99f4-e48189979...@gmail.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
Creating a copy of a database -- best practice?
I can easily do something like this:
CREATE DATABASE C:\Backup\MyDBC.dbc
OPEN DATABASE C:\Production\MyDBC.dbc
liNumTables = adbobjects(laTables,'TABLE')
for ii = 1 to liNumTables
lcFile = forceext("C:\BACKUP\" + laTables[ii],'dbf')
use laTables[ii]
copy to (lcFile) database C:\Backup\MyDBC.dbc with cdx
use
endfor
...and that would get me a copy of all of the tables with their indexes.
Great. But what's the easiest way to get all of the DBC meta-data into
that new Backup database copy? I can't USE the MyDBC.dbc and do a COPY
TO as that only makes the result a DBF and FPT.
Trying to think about a good disaster recovery plan (besides using
CleverFox from Rick Schummer and Frank Perez...which is probably the
best option!) for automating backups at the client who just got that
ransomware virus.
tia,
--Mike
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/500593bf5f84e661f7648a5121a41...@mbsoftwaresolutions.com
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
