Re: [Gnumed-devel] Corrupt database

[Karsten Hilbert]

> I have renamed gnumed _v18 to gnumed-_v18 old and bootstrapped. I can access 
> data old system by renaming and then connecting.

That is a good idea.

I think you can also set up a profile with the database name gnumed_v18-old 
such that you can just
access the database from the login menu as you need it - you could even keep 
two clients
running next to each other (but be careful to remember which is which).

> Plan is to write soaps as pdf for all 300 patients and attach the pdf as 
> documents to present
> system at leasure time.

That would be possible using document templates, I guess, perhaps using

   $emr_journal::...$

?

> This work can be eased if I can import demographic table.

Due to the fact the each patient can have many names and many addresses and many
comm channels and many external IDs it is not at all trivial (even if 
restricting
to JUST names) to write demographics into a "simple" CSV file.

However, now that you've got a "proper" database which really SHOULD have all 
the
bells and whistles in terms of constraints and checks you could do this:

- delete all the data from the new database per Jerzy's description
- if that doesn' work:
   - create a schema-only dump of the new DB
   - drop the new DB
   - restore the schema-only dump :-)
- create a data-only dump from the old database (with psql)
- restore that data-only dump into the new DB

Upon restoring PostgreSQL will tell you where your data does not meet
the constraints and you can show us and we can tell you what to remove
from the dump in order to restore.

> I had taken backup from schema dem, but I am not sure
> 1. Restoring the particular table will cause any problem with fresh database 

It depends on what is already in the new database.

> 2. How to drop a readonly table 

set default_transaction_read_only to off;
drop table ...;

> 3. Is there any other way of copying one table to other.

insert into ... select from ...;

> 4. How can I check a database integrity regularly. Can it be automated.

If it could it would have been.

Every client connect checks the schema structure (with 1.4 including Foreign 
Keys).

Every upgrade checks to original and the new database both in
terms of data and schema.

Every data pack install checks compares before and after.

This effectively means you must have done something to the database
at one point which was outside of GNUmed's control (say, restoring with
checks switched off).

PostgreSQL 9.3 is likely to offer disk file checksumming.

Some filesystems offer disk data checksumming.

Some drives don't lie about fsync.

RAID helps with hardware corruption.

> I am aware you have not liked this path and that I did not try to repair it 
> instead. But I cannot keep it pending . 

Well, a shortcut is not always the shortest path. But at any
rate you need to do what you see fit.

Karsten