>Of course all of us want Tim devoting his efforts to improve EDB (a great product yet), wasting time creating an editor is not a goal. I think is a good idea to integrate a 3tr party editor. The way to do is, I don't know it.

Since EDBManager is basically a wrapper around ElevateDB functionality developing your own would be simple - just take a lot of time.

There is no secret code in there just standard ElevateDB calls and Delphi programming. I'm sure that most of us have duplicated much of the functionality in our own apps - eg loading and running a migrator. In my opinion the biggest problem would be the feature set and UI that should be implemented. We all will have our own views and those will often be in conflict.

If we want a co-operative project to produce a manager we could go for it. I do remember that there were a number of 3rd Party managers for DBISAM. I played with some but always went back to DBSys. Unless a competitor was well thought out and implemented and kept up to date I'd probably end up going back to EDBManager.

If you seriously want to build a competitor please respond to this thread


Roy Lambert

I'm responding to the thread, but have no intention at all of building a competitor!

I started my original thread with "EDBMgr is a great product" ... honestly I still think this! I don't want to use another editor, especially as it is so highly dedicated to EDB, which no other more general-purpose product could be.

Really the problems are minor ones:

* Some annoying handling of CTRL + ARROW behaviour (and this only when you are within a string in a SCRIPT, the rest of the time it is fine).

>>I don't think this requires a rewrite! A tweak could do it.

* Some difficulties with navigating multiple SQL Windows when you have many open.

>>This could be fixed by improved naming of the NEW.SQL

* Some difficulty knowing which Database your query will run against ... if you are focused on DB "X" in the tree, then the query runs against this, but when you have a very large tree it can be hard to see where you are.

>>Your suggestion of including the DB path in the Application.Title would fix this.

* Personally I would like a visual query builder ... just for creating cumbersome SELECT statements without having to type _everything_

--

There is lots I love about the product ... I love running SQL with Debug-breakpoints for example! I love being able to transform tables into CREATE SQL by dragging and dropping ...

--

There is a way around this, which might be to somehow open the product to packages in the way that Delphi does? This is probably much to heavy-handed and complex, but if it could be done it would allow someone to build something like a new editor or Visual Query Builder & making it into a plug-in??

Adam

>I'm responding to the thread, but have no intention at all of building a competitor!

Neither have I I was just pointing out that this was an alternative

>There is a way around this, which might be to somehow open the product to packages in the way that Delphi does? This is probably much to heavy-handed and complex, but if it could be done it would allow someone to build something like a new editor or Visual Query Builder & making it into a plug-in??

Might be difficult for Tim to achieve but I do like the idea.

If he does his normal good job he can then sell the plugin framework as a product

Roy Lambert

Adam,

<< * Some difficulty knowing which Database your query will run against ...
if you are focused on DB "X" in the tree, then the query runs against this,
but when you have a very large tree it can be hard to see where you are. >>

The active session/database names are always found in the status bar on the
bottom right-hand side.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< * Some difficulty knowing which Database your query will run against ...
>if you are focused on DB "X" in the tree, then the query runs against this,
>but when you have a very large tree it can be hard to see where you are. >>
>
>The active session/database names are always found in the status bar on the
>bottom right-hand side.

And if you do as I did and copy the live data over the development data that still shows exactly what it would have done when the database was pointing at the development machine rather than the live one.

Roy Lambert

>>And if you do as I did and copy the live data over the development data that still shows exactly what it would have >>done when the database was pointing at the development machine rather than the live one.

OUCH.

I have a situation where I am remotely connected to the "Live" data, but also have the test data on my home / office machine.

I live in fear of running some "test" SQL on the live data because I am focused on the wrong part of the tree.

Adam


>I have a situation where I am remotely connected to the "Live" data, but also have the test data on my home / office machine.
>
>I live in fear of running some "test" SQL on the live data because I am focused on the wrong part of the tree.

That's basically what I did. To try and make sure I know where I am my apps have a colour scheme that is (generally) ghastly for development and nice for live. I also alter my login on development to XX from RL. Having just copied stuff over I ran a script to stop it being live and making it development (user ID, email addresses, phone numbers etc all "safed"). As with many instances of global changes it was not possible to reverse.

Then I had a problem with backups not working correctly (I use Acronis)


Arrrrrgh

Roy Lambert

Roy,

<< And if you do as I did and copy the live data over the development data
that still shows exactly what it would have done when the database was
pointing at the development machine rather than the live one. >>

I'm not sure what the EDB Manager could possibly do to prevent you from
making that mistake.  If you use the same database names for both live data
and test data, then you need to make sure to be extra careful about what
you're doing.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


>I'm not sure what the EDB Manager could possibly do to prevent you from
>making that mistake. If you use the same database names for both live data
>and test data, then you need to make sure to be extra careful about what
>you're doing.

Very little can actually stop you ignoring warnings, however, its helpful if the warnings are there. The only one in EDBManager is the session/database name which most of the time is enough. I don't copy the live data straight over very often (I think 3 times in the last 2 years or somesuch) and only when I've totally screwed the development database.

The problem here was that I could see I was in the development session but I couldn't see that the database was pointing to the wrong directory. That piece of information was hidden by the Log Message pagecontrol.

All I'm asking for, as I have before, is that the path to the databases displayed PROMINENTLY and at all times unlike the current situation where its at least partly hidden when shown and frequently not shown.

Roy Lambert

I have the same issue sometimes -- running a statement against a local database where a production version also exists.  I'm real real careful, but once I did alter the remote one inadvertantly (recoverable).

But here is a simple idea.  Might seem like an overkill (until one really inadvertantly does somthing)...

- Have the session have a new flag and checkbox: "This is a production database"
- On any operation in EDBM that is going to alter the database (or maybe just any operation), prompt with a simple message box: "This statement/script is about to run against the production database <database name>.  Proceed?"

Simple to implement, easy to turn on/off, and once in a while might just save our neck.


On the question this thread was about -- I find EDBM to be well more than adequate.





C