Icon View Thread

The following is the text of the current message along with any replies.
Messages 21 to 30 of 43 total
Thread Questions on Catalogs
Wed, Oct 29 2008 1:27 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Stefano,
<< Yes, Tim. This is that I want (sorry,...I like) ; One catalog that
control more than one database; >>

See my response to Roy.

<< The best is if I can distribuite an "updated" catalog and all related
database change automatically the structure on connect (but this involve too
events and cannot be "automagically"). >>

This is what gave me the impression that you wanted the table structure in
the table files.  That's the only way to accomplish what you're describing
here.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thu, Oct 30 2008 3:09 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim


>Well, there are technical issues with it that make it very unattractive
>also.

I would say challenging rather than unattractive

>Consider a situation where a table is altered. This would then
>result in N number of alterations across all database directories that are
>sharing the same catalog.

Yes that is an expected, and desired consequence

>Furthermore, how do you know which set of table
>files belongs to which database catalog ?

Much the same way as you do now - you have some data stored in the catalog (or is it the configuration file?) but rather than a single VARCHAR holding a path you have a CLOB holding a list of paths or somesuch.

>What if there's a catalog file
>present in a database directory, but the table files aren't using it ?

It gets ignored and goes and sulks in the corner Smiley

>What
>happens during a restore ? etc.

Probably much as happens now, data is extracted from a compressed file and put where you tell it, and as now if the data restored isn't compatible with the catalog in use you're stuffed.

I accept that its not going to happen which I personally regard as a shame because a) it would be dead useful to me and b) it would make a great USP.

Roy Lambert
Thu, Oct 30 2008 5:44 AMPermanent Link

"Iztok Lajovic"
Roy,
>
>>Consider a situation where a table is altered. This would then
>>result in N number of alterations across all database directories that are
>>sharing the same catalog.
>
> Yes that is an expected, and desired consequence
>

I am deeply convinced that managing such table alteration is much better
done with code. Let imagine that one has for some reason to restore data
from an older backup where data structure is not the recent one while
arcihive was done in time when table alteration didn't take place yet.  How
to deal such situation with catalog while it doesn't know details of some
past data structures? How it could then transform old structures to new
ones?

We have an financial application on multiple places and this application is
alive. That means that we sometimes have to change some table's structure
depending on new functionalities. In the application there is a starting
module which checks version numbers of every table and if there is
difference then the code makes appropriate table restructure. It happens
that the user has to check some data from years ago which are not more
present in actual tables and he/she has to restore data from backup. This
starting module checks all tables and makes all needed restructures to get
the recent structures. Therefoe we don't have to deal with old structures in
other parts of application or to use dbsys to get recent structures
manually.

DBISAM had for dealing such structure alterations fantastic methods, but on
other side with ElevateDB there is a bit more work but it works for us
ideally. It is worth to consider of making restructure modules by yourself.
Central catalog requires change of ElevateDB basic concept with lot of
consequences that maybe could harm a lot of other developers that not need
the change.

It is not a good development policy if Tim had incorporate in ElevateDB
every idea, especially if it could be done by developer itself without much
effort

Iztok Lajovic

Thu, Oct 30 2008 5:51 AMPermanent Link

"Stefano Monterisi"
Hi Tim,
my great fear is this: I distribuite applications to people that I don't
known (and that are'nt experts); peripheral databases are collected to
regional centers (databases remain always separate); regional centers send
all data to a national center, that mantain all databases, always separated
from each other;
All this people can easily substitute catalogs with terrificant result
(there are catalogs with the same catalog name in every folder ? (databases
are collect within different folders)).
This is my fear; Is not possible to distinguish catalogs files between them,
true?

Good job,
Stefano Monterisi


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> ha scritto nel
messaggio news:D5538E5F-3AE0-4088-8B07-202A75FF262B@news.elevatesoft.com...
> Stefano,
> << Yes, Tim. This is that I want (sorry,...I like) ; One catalog that
> control more than one database; >>
>
> See my response to Roy.
>
> << The best is if I can distribuite an "updated" catalog and all related
> database change automatically the structure on connect (but this involve
> too events and cannot be "automagically"). >>
>
> This is what gave me the impression that you wanted the table structure in
> the table files.  That's the only way to accomplish what you're describing
> here.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Thu, Oct 30 2008 6:49 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Iztok

>I am deeply convinced that managing such table alteration is much better
>done with code. Let imagine that one has for some reason to restore data
>from an older backup where data structure is not the recent one while
>arcihive was done in time when table alteration didn't take place yet. How
>to deal such situation with catalog while it doesn't know details of some
>past data structures? How it could then transform old structures to new
>ones?

In those circumstances you are correct code (Delphi or SQL) would be the best approach and having one catalog controlling multiple sets of data would make it harder to manage.

Roy Lambert
Thu, Oct 30 2008 8:53 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Stefano,

<< my great fear is this: I distribuite applications to people that I don't
known (and that are'nt experts); peripheral databases are collected to
regional centers (databases remain always separate); regional centers send
all data to a national center, that mantain all databases, always separated
from each other;
All this people can easily substitute catalogs with terrificant result
(there are catalogs with the same catalog name in every folder ? (databases
are collect within different folders)).This is my fear; Is not possible to
distinguish catalogs files between them, true? >>

Correct.  However, what you're suggesting would make the problem worse, not
better.

As for messing around with the contents of the database directory, this is a
strawman argument.  *Any* database will suffer if a user/administrator
starts messing with the actual physical files without knowing what they're
doing.  If you need to replicate data around, then you should consider using
the replication in EDB instead of copying around the database files
themselves.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thu, Oct 30 2008 8:56 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< Much the same way as you do now - you have some data stored in the
catalog (or is it the configuration file?) but rather than a single VARCHAR
holding a path you have a CLOB holding a list of paths or somesuch. >>

I was referring to the actual physical files, not the internal
implementation.  There would be no way to know from an external view, what
files belong to which databases.

<< I accept that its not going to happen which I personally regard as a
shame because a) it would be dead useful to me and b) it would make a great
USP. >>

It would also mean re-designing the entire engine from bottom to top.  I'm
sorry, but that just isn't in the cards.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thu, Oct 30 2008 10:38 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim

>It would also mean re-designing the entire engine from bottom to top. I'm
>sorry, but that just isn't in the cards.

One of these days, when I win the lottery, I'm going to buy the source code version just so I can argue points like that <vbg>

Roy Lambert
Thu, Oct 30 2008 11:27 AMPermanent Link

Fernando Dias

Team Elevate Team Elevate

Iztok,

> In the application there is a starting
> module which checks version numbers of every table and if there is
> difference then the code makes appropriate table restructure. It happens
> that the user has to check some data from years ago which are not more
> present in actual tables and he/she has to restore data from backup. This
> starting module checks all tables and makes all needed restructures to get
> the recent structures.

I use exactly that same design in all applications.
Every database is checked at startup, table by table, and the
appropriate changes are applied before any other operations. The code
needed to restructure is present in every version of an application
since it's birth and is cumulative, so every past version of the
databases/backups can be opened with a newer version of the application.

--
Fernando Dias
[Team Elevate]
Thu, Oct 30 2008 12:51 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< One of these days, when I win the lottery, I'm going to buy the source
code version just so I can argue points like that <vbg> >>

You're part of Team Elevate, you can have the source code now if you want.
I think you'll see that it is a little more complicated than you might
think.

--
Tim Young
Elevate Software
www.elevatesoft.com

« Previous PagePage 3 of 5Next Page »
Jump to Page:  1 2 3 4 5
Image