I am continuing to work with Replication in EDB pretty well. Its not totally easy ... but it all works.

I just had to do a small change to my db structures. There was quite a lot of posting on the main forum about it. In the end I found a way to do a basic update process (by stopping everything for a couple of days! ) ...

However after restart 1 update file from 1 user wouldn't load. As my update job ran all the updates in order (which it has to) this meant that the whole update process stopped.

In the end I crossed my fingers, deleted the 1 problematic update and ran the job ... which was fine.

I _think_ something in this update must have dated from the "old" version of the database & therefore not uploaded.

--

The key issue is it would be great to be able to see inside each update at some level to be able to get an idea of "what's there" to help when you need to poke around in the update process ...

I mentioned this in a previous feature request ... but I thought I would ask again, as this additional factor makes the need more important than before.

Adam

Sorry, a second, related process I forgot to mention first time ...

It would also be great to be able to do some sort of "diff-check" between 2 versions of a database where a replication process was going on.

i.e. is DB1 now (after the update) actually identical to DB2. It is possible for an update to happen and the 2 db's to still be out of sync ... which can be a problem.

I know DB tables have "PUBLISHER IDS" which are GUIDs and therefore lack any cardinality. But it would be great to be able to do basic cross-checks beetween tables, such as table-by-table which DB was updated last, which table was larger than the table with the same name on the opposite side.

I know Roy is going to say that I should write a Delphi App to do that ... he's right of course! But it would be great to think about some of the above functionality in the context of the EDBManager & SQL Statements too.

Adam


>I know Roy is going to say that I should write a Delphi App to do that .

No he's not. What he's going to say is he's not totally certain what you're asking for, and wether the data exists anywhere to do it to start with.

And I know this cos I am Roy <g?

The main problem I am having is lack of certainty about when / whether an update has run between different parts of an interlinked, replicated database.

I open EDBMgr & have sessions pointing to different databases. I can immediately see (in the "Details" Pane) when & whether a table is published etc., the tables buffer size & things like that.

However I can't see fairly basic things like Row-count, size of the table file on disk in bytes, date the file was last updated or changed, whether there is a live update file for this table with outstanding updates which have not yet been saved, whether a SQL script has generated a change in the db structure resulting in an "OLD" version of the table which is now hanging around on disk.

Some of the above can be seen with Windows Explorer, but if the session is remote viewing such data requires a remote session for each different database, which is slow.

Also, more complex information (which I know might be technically impossible to get) such as when an UPDATE file was last loaded into a database or table, when a user last connected etc., is also not visible in EDBMgr.

This makes it hard to easily assess how similar 2 versions of 1 table in different databases are, at what level they are being used by different users etc., which is useful information to have as an Admin.

--

A lot of my need for this data is very specific to me, so I will probably have to write an application to do it myself, but some of it is more general & could perhaps be included in EDBMgr.

Adam


As I suspected <evil grin> the very data for some of what you're asking for doesn't exist as far as I know.

I think you're right and that you'll have to implement at least some of it yourself, Tim may at some point build some of it in. To take a few of your points

<<However I can't see fairly basic things like Row-count, size of the table file on disk in bytes, date the file was last updated or changed, whether there is a live update file for this table with outstanding updates which have not yet been saved, whether a SQL script has generated a change in the db structure resulting in an "OLD" version of the table which is now hanging around on disk.>>

Row count can only be found by opening the table (and it is shown then) - pretty much the same as with DBSys, but there you had to open the table to get at ANY of the information. Its not a great deal of use since the number of rows is dynamic and to do anything sensible EDBManager would have to keep on refreshing the count.

Table disk file sizes - hmm Windows API call to get them, bit of code to add the three together, and again subject to change as stuff is added, deleted, the table optimised or restructured.

File dates - which one would you like  remember there are upto three files and its possible that they could be changed independently, again Windows API calls, again subject to change

Live update file - sounds sensible but I don't know what I would do with it, you probably have plans.

OLD files. An SQL script changing the structure isn't the only thing that can create an OLD file, I don't think Tim differentiates between the various ones so not as useful as you would like.

One thing I know Tim is very much against is any form of "transactionalising" the catalog which is what he'd have to do to store such information as date last updated

Next question - are you more concerned about casual messing about or the implementation of your replication / update scheme?

If its the former - suffer - if the latter then think about a token passing scheme. Even if the information you're asking for is available somewhere via SQL, Delphi, Java or whatever passing tokens will be easier to control and extend. At least in my opinion.

Roy

Adam,

<< I mentioned this in a previous feature request ... but I thought I would
ask again, as this additional factor makes the need more important than
before. >>

It's queued up for the next release.  If I ever get EWB done, then it will
get addressed ASAP.

--
Tim Young
Elevate Software
www.elevatesoft.com

>>It's queued up for the next release.  If I ever get EWB done, then it will
>>get addressed ASAP.

We are all extremely excited about both these releases ... thanks in advance for the inclusion of anything in EDBMgr which helps to re-code or make visible the contents of an EDBUpd file.

Thank you Roy,

Good points.

>>Row count can only be found by opening the table (and it is shown then)

I would still quite like EDBMgr to just fire a COUNT(*) Query on the table when generating the information shown in the "Details" pane, so I as admin can see the total number of rows when comparing different versions of a table.

I know its a bit of a kludge & row counts may differ (or be the same!) for other reasons, but it would still be useful

>>Table disk file sizes - hmm Windows API call to get them, bit of code to add the three together, and again >>subject to change as stuff is added, deleted, the table optimised or restructured.

>>File dates - which one would you like  remember there are upto three files and its possible that they could be >>changed independently, again Windows API calls, again subject to change

Actually data for the date-last-change and size of each of the three files (data, index & blob) would be really useful, again displayed in the "Details" pane of the EDBMgr when the user focuses on a table.

>>OLD files. An SQL script changing the structure isn't the only thing that can create an OLD file, I don't think Tim >>differentiates between the various ones so not as useful as you would like.

>>One thing I know Tim is very much against is any form of "transactionalising" the catalog which is what he'd have >>to do to store such information as date last updated

You are right this is too complex to try to get hold of.

>>Next question - are you more concerned about casual messing about or the implementation of your replication / >>update scheme?

Both: I think the extra data would make some day-to-day checking & admin tasks easier.

In terms of replication I am struggling with a mechanism to manage change to a database structure which has to be able to migrate across a cloud of users. In this situation I need to (try to) keep track of which user has had which updates ...

>>If its the former - suffer - if the latter then think about a token passing scheme. Even if the information you're >>asking for is available somewhere via SQL, Delphi, Java or whatever passing tokens will be easier to control and >>extend. At least in my opinion.

Good advise, thanks.

Adam


One thing I've asked Tim for (it was asked for in DBSys but would have been hell to introduce there) is a plug-in mechanism so we can extend EDBManager. What you're asking for would be a great use of such a mechanism. I wouldn't want to much excess baggage being run when I click on a table, or cursor up and down as I do when trying to remember what I was doing but a button or menu option to give me the info would be brilliant, especially if I could set it up to give me just what I want.

I'm sure the next time he visits Tim will tell us whereabouts in the heap the suggestion is.

>In terms of replication I am struggling with a mechanism to manage change to a database structure which has to be able to migrate across a cloud of users. In this situation I need to (try to) keep track of which user has had which updates ...
>
>>>If its the former - suffer - if the latter then think about a token passing scheme. Even if the information you're >>asking for is available somewhere via SQL, Delphi, Java or whatever passing tokens will be easier to control and >>extend. At least in my opinion.
>
>Good advise, thanks.

Have a look at what I posted before. It will generate a bit of network traffic but implemented correctly will give you a lot of control, you can even allow people back into the system as soon as they pass GO whilst still sending others to jail

Roy Lambert [Team Elevate]

Adam,

<< We are all extremely excited about both these releases ... thanks in
advance for the inclusion of anything in EDBMgr which helps to re-code or
make visible the contents of an EDBUpd file. >>

It gets asked for by everyone that uses the replication, so it definitely is
something that is necessary.

--
Tim Young
Elevate Software
www.elevatesoft.com