Our servers went down for over 6 hours yesterday and I was asked if
there was a way to store the database on the server and a local station
at the same time.

My datbase is split and the tables are linked. Would there be a way to
modify the table links to direct them to two seperate backends? Could
there also be a non-linked table stored in the frontend alongside the
table links?

Our endpoint would be to have a mirror on the network drive that all
users could use, but in the even of another server downtime, the
dispatcher could use the mirrored tables that are stored on the local
drive without using a different frontend MDE?

Thanks

Dave

> My datbase is split and the tables are linked. Would there be a way to[color=blue]
> modify the table links to direct them to two seperate backends? Could
> there also be a non-linked table stored in the frontend alongside the
> table links?[/color]

Why would you want to have double links?
In case the network gets down you can copy the backend-db to a local station, refresh the links and work on the local station with the local db.
You can use code to refresh the links automatically. I do this with all my apps.
(Well in fact I delete the link and recreate it, this 'sometimes' works better because links can get corrupted)
Code to just relink is here:
http://www.mvps.org/access/tables/tbl0009.htm

--
Hope this helps
Arno R

Our server is not located in the same place we are. If the network
connections drops, I cannot get to the server. If I were to have a
mirrored backend locally, using the code you linked to me would provide
a near-seamless backup. The only issue now is how to establish a local
backend and have it exist with a network backend.

Thank you for your help

Dave

Dave,
Maybe you could automate some kind of 'pseudo' backup-mirroring procedure??
Could you send your data from the server to you locally, every hour or so ?
You can automate this from within your mde-frontend.
When the appp is running it sends the date every hour or so.
If you are the only user this will work. If it's multi-user it's more difficult.
I 'think' you will have to make more backups then, because you can not be *sure* such a 'live'-backup is a good one.

Good luck,
Arno R

<nydiroth@yahoo.com> schreef in bericht news:1113673864.189660.98120@o13g2000cwo.googlegro ups.com...[color=blue]
> Our server is not located in the same place we are. If the network
> connections drops, I cannot get to the server. If I were to have a
> mirrored backend locally, using the code you linked to me would provide
> a near-seamless backup. The only issue now is how to establish a local
> backend and have it exist with a network backend.
>
> Thank you for your help
>
> Dave
>[/color]

It is multi-user after the data is entered. The primary key is our
incident # which is generated from the dispatcher. Once a call is
placed a dispatch card is started and a incident # (PK) is generated.[color=blue]
>From there the dispatcher can click a button to generate a new report[/color]
(Incident or Property) based on the incident type. Everything is
dependant on that incident #. So, in one sense it is multi-user as we
can use different stations to complete the reports, but it stems from
the generation of the PK from the dispatcher. Hope that is not
confusing.

If the network goes down, it is not a big deal if the reports are not
completed as they will not be able to be emailed to the commander and
higher, but the chronoligical(sp) integrity needs to be maintained. To
do this I would need a backup generated after each incident card is
completed. I am figuring if I can have the backend saved locally and on
the network at the same time, it would prevent a lagtime for creating a
backup after each card.

Thanks
Dave

I've been reading about replication and it sounds like the way to go. I
cannot find anything here or other places about an automatic synch or
an ongoing synch as long as the database is open.

Any ideas?

Thanks
Dave

Dave,
I have never used replication myself, but from what I know about replication I think it will not be your solution.
When your network goes down you can't replicate anymore...

Maybe your first idea (double tables, double links) was not so bad at all.
I think I understand your problem now...[color=blue]
> I am figuring if I can have the backend saved locally and on
> the network at the same time,[/color]
In that scenario I would not save the whole backend but only the new records.

Just an idea here: Maybe this is what you are after?
You could have *exact* duplicates of your data-input-tables in a local 'replica'-backend.
Link the 'same' tables two times, first from your backend, second from your local 'replica'
Name your second linked 'replica-table' the same as your first linked table but 'Replica' added
Like: TabInput and TabInputReplica
You can now duplicate every new record to these tables. (I would use Transactions here.)
In case of a Network-failure you only have to rename the links (and other stuff like stop duplicating...)
It's difficult but you get the idea? It is the best I can think of right now.
--
Hope this helps
Arno R


<nydiroth@yahoo.com> schreef in bericht news:1113681001.164969.76440@o13g2000cwo.googlegro ups.com...[color=blue]
> I've been reading about replication and it sounds like the way to go. I
> cannot find anything here or other places about an automatic synch or
> an ongoing synch as long as the database is open.
>
> Any ideas?
>
> Thanks
> Dave
>[/color]

Figured it out. Maybe not the best,but it works so far.

<CODE in afterupdate>

DoCmd.SetWarnings False
DoCmd.CopyObject acoutputtable, "tabelname", acTable, "tablename"
DoCmd.SetWarnings True

</CODE>

Thank you so much for your help.

that way I can quickly copy only the table after each record is
changed.

Thanks for