On Thu, Nov 5, 2015 at 5:18 AM, Peter Cushing
<[email protected]> wrote:
> I should image it would be difficult copying the data out to text when you
> have memo fields.

Memos and blobs (General and Picture fields) present special issues,
but you write off the contents to a separate file, uniquely named, and
append to a new table from there. It's not a single-file solution, but
can be accommodated. It's been done in SCCTEXT, FoxBintoPrg and the
BinToText utilities.

> For what you are doing I can't think of anything better than the ZIP file
> solution you mentioned.  Your database contains all the structures/indexes
> and data that you need so why not use that format?

Well, it's the binary-vs-text debate. It's easy to diff a text file
and determine what has changed, whereas diffing a binary only says IF
it has changed.

> We have a backup solution running every couple of hours that has a copy of
> the database in another location and just appends the data to this, then
> makes a date/timed copy of in another folder.  If your system went down you
> could copy this straight back and it would work fine.  Instead of dumping
> the data it is dragging the data.

Yes, this isn't intended as a backup technique (though it likely could
be extended to do so) but more a utility to use with a developer's
environment to restore to a known point. Yes, I could use ZIPs but
it's more opaque.

There are lots of good use cases for this:

-- two clients with "identical" apps running into different
unreproducible issues. You generate text for the structures and they
are identical. You generate text from the data, and find one has
changed their lookup tables so that "Credit" is "Debit" -- ah-ha!

-- Working with your development test data, you're getting different
results this week than last. You diff the data and find that you've
inadvertently deleted one of the records in the workflow.

I'm sure there are other examples, too.

>
> HTH
>
> Peter Cushing
> IT Department
> WHISPERING SMITH
>
>
> On 04/11/2015 20:51, Ted Roche wrote:
>>
>> Hi, folks:
>>
>> Thought I'd break the quiet with an on-topic question.
>>
>> In several other database backends I deal with, there's a command to
>> dump the contents of the database to text so that you can restore it.
>> MariaDB has mysqldump, PostgreSQL pgdump.
>>
>> Is there a "simple" way to dump:
>> -- table structures
>> -- indexes
>> -- actual data
>>
>> and use the resultant SQL or PRG to create an identical new database?
>> Same structures, indexes and PK/FKs? I need to run a series of
>> destructive tests and I'm looking for a solution more elegant than
>> "ZIP the old data, break it, blow it away, unZIP the old data..."
>>
>> I've cobbled together bits and pieces of this before using parts of
>> GenDBC and various COPY TO TYPE DELIMTED and various hacky commands
>> like:
>>
>> ALTER table clients alter COLUMN iid int AUTOINC NEXTVALUE (MaxClientPK)
>> STEP 1
>>
>> but wondered if there was a Power Tool out there I'd missed.
>>
>> TIA,
>>
>> TR
>>
>
>
>
>
>
>
> 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:17-19 Foley Street, London W1W 6DW Tel:0207 299 7960
>
>
[excessive quoting removed by server]

_______________________________________________
Post Messages to: [email protected]
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/CACW6n4t4p=uavno0p2o+o0-rhme+mkd_6fecsw3wmbsunre...@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.

Reply via email to