Hi Jason,

This comes a little late.

I am planning to write some roll your own replication. Since you have
done some of this, just bouncing ideas and asking questions on some
of your points.

1. I dont need a complete replicate. The application updates users
task lists at various locations (Think of it as a primitive
workflow). so instead of just PK,tablename and action will also
maintain "send to location".
2. Instead of sychronising generators all PKs are 64bit and
initialised differently at each location. So data created at one
location will have particular series of PKs but data inserted because
it was sent from some other location will be created using the PK
generated at the remote location.
3. What are generic non table bound triggers and how is it useful for
replication?


Regarding shadowing - I feel it is a pretty reasonable solution even
today. However only for apps which are shipping as products for SOHO
or departmental use in a large organisation and using firebird as an
embedded server. The server may be getting installed in an
organisation that does not have an IS department or getting
installed on the fastest machine in a department. People dont there
dont know what is RAID. So if one hard disk crashes you may not be
able to do a automatic failover. However, even though it may a take
a day or two or even more, it is possible to restore the latest
data. (Just thoughts I have not done it. I intend to set it up this
way for one of my applications so I am curious to know if this would
work. Any gotchas in using it like this)


Thanks
GK

--- In ib-support@y..., "Jason Chapman (JAC2)" <jason@j...> wrote:
> Sounds to me like you are after replication. I support a site that
have
> multiple "report" and near live servers running as backups to the
main
> server, we use role your own replication.
>
> The main issue you will have past replication itself (we used the
variety
> that just puts the PK, tablename and action (insert / update /
delete) into
> a replication table, is that all DB's have to have the same
structure and as
> such when you want to promote a backup to a live you need to:
> 1) Report on how up to date you believe the DB to be (on this
system it
> ranges from 0s to 60 minutes depending on load etc, but 60 minutes
is
> usually after a massive single transaction update).
> 2) Be able to synchronise the generators
> 3) Enable the replication triggers (I am wetting myself about the
generic,
> non table bound triggers!).
>
> Doug Chamberlain (sorry for the spelling) wrote a wonderful short
brain dump
> on issues surrounding robot processes a couple of years ago.
>
>
> I wouldn't be surprised if shadowing bit the dust sooner or later
as a FB
> feature, I certainly wouldn't vote to keep it.
>
> HIH
>
> BTW I was on a new client site today and got a report that was
taking 8
> hours down to < 1 minute, don't you wish every day was like this?
>
>
> Jason Chapman
>
> JAC2 Consultancy
>
>
>
> Training - Development - Consultancy
>
> Delphi, InterBase, Firebird, OOAD, Development lifecycle assistance,
> Troubleshooting projects, QA.....
>
> www: When I get round to it....
>
> Mob: (+44) 07966 211 959 (preferred)
>
> Tel: (+44) 01928 751088
>
>