Roy Lambert wrote:

Jorge


I'm having difficulty in making a reply without causing offence. I've deleted four before posting so far. I apologise in advance if anything I post below offends. That's not my aim. On this forum we like to help but it can be difficult.

You are asking very specific questions without giving enough information. It comes across as though you've got yourself in a corner with a system design that should have been better thought though to start with. As Matthew says what you have sounds very fragile.

What we don't know so far:

1. transaction volumes
2. database design
3. operational mode (are databases updated via sql or table navigational methods)
4. database size

There'll be more. I know there's a language barrier to overcome but from your posts I'm very uncertain as to your skill level. I have no idea how the system operates apart from the fact that there are positings going in every second and that you never delete anything. So here's another question or so

5. is the system simply used to record input or are reports produced
6. what is the maximum acceptable delay between something being posted and it appearing in the database
7. do the postings have to go into the live database or could there be an intermediate database for data capture
8. do you have any disaster recovery plans
9. you have 5 servers (30 users) and 50 local users - how are they connected


Looking at what you've posted so far I also have to ask if you've considered hardware / cloud based solutions

There are a lot of ways that things can be done to help - using ElevateDB triggers (horrible to write but workable) to write out to a duplicate table, subclassing the TEDBTable component to do the same thing, using the inbuilt replication, paying someone to do a custom replication system for you, disk mirroring, cloud mirror, but without knowing a lot more I wouldn't like to suggest an approach.

Roy Lambert

Roy...

No offense at all.
I design systems for 25 years starting with Delphi summer 87, for maybe 200 companies from small to big, so I guess that I know wath I am doing.
It is true that I am a Spanish speaking person, so the lenguaje is a little barrier. I am based on Ecuador.
My first choice since existed was always ADS.
In the situation that ADS was acquired by SAP, it is not a suitable product for us anymore for a lot of reasons (suppor,etc)
I studied maybe 10 alternatives for replacement keepin in mind that ours developers environment most of the cases is Delphi.
And the winner for me was ELevateDB.
We are currently using it ini small parts of our projects, but my intention is to full replace ads.

It just that the replication system in my point of view, could be hot. Would be a goood feature.
I understand perfectly that ELevateDB is a very good product, and I am happy to own it and used it right

I keep in mind your comments, to be strict and specific in my next posts.

Best regards and thanks for your support.

And Roy, we are 100% commited to use EDB in our current and future projects.

This is the first, that came out for a little customer, one of many more.

Keep the good work!

Jorge,

<< The backup locks the database, and the save updates too (like a smaller backup), >>

I think you're overestimating how much time the SAVE UPDATES statement will take to run. And, if you're using the new global file I/O buffering with the EDB Server, things will be very fast.  This functionality uses internal read/write locks that are very, very fast, and, if you configure the buffering properly, EDB will very rarely touch the disk for reads. This means that the amount of time involved is in the milliseconds range, not the seconds range.

<< When you "save updates", maybe a second file could take over, and store the updates that you missed while the saving update is being proccesed and stored. After finish, the second file become primary. i guess that in that way, you dont have to acquire the lock while your are saving the current update and the tables still always ready to write access. >>

You're still going to need to use a read lock on the table to prevent anything from changing while the "switchover" is taking place.  You have to remember that EDB still supports file-sharing access to databases, so there are limits to what can be done without breaking that functionality (which I cannot do at this time).

Tim Young
Elevate Software
www.elevatesoft.com

"I think you're overestimating how much time the SAVE UPDATES statement will take to run. And, if you're using the new global file I/O buffering with the EDB Server, things will be very fast.  This functionality uses internal read/write locks that are very, very fast, and, if you configure the buffering properly, EDB will very rarely touch the disk for reads. This means that the amount of time involved is in the milliseconds range, not the seconds range."



Thanks for the advice Tim,
I will try this approach and let you know the resutls later on.

Jorge,

<< I will try this approach and let you know the resutls later on. >>

Feel free to email me if you're not seeing satisfying results, and we'll figure out what's going on.

Tim Young
Elevate Software
www.elevatesoft.com