Hi Tim,

I'm testing beta and have already managed to create an adapter for it for
the designer
There are a number of issues with it obviously, (freezing mostly and list
index
out of bounds in Manager) but that is as expected, I guess.

Here's one [design] issue, though, that I can't seem to comprehend.

In DBISAM we use to have separate DatabaseName - name of the
database in the context of application - this is the name all table and
query components connect to the database component in the data module.
Separately we use to have Directory - for local databases and
RemoteDatabase for remote databases. This way, if you need to
point your local database instance to a different remote or local database
you only had to change one property, namely RemoteDatabase\Directory
(why those are two different eludes me at the moment .

Now, in ElevateDB I was unable to locate Directory or RemoteDatabase
property. Instead I see that DatabaseName property is matched directly
against
the Session configuration database.... So, if I'm understanding it
correctly,
if I need to change the actual name of the database on server (say, I work
with
two databases Data and DemoData registered on server), I have to change the
DatabaseName property - which will require changing it for ALL table
components, because they are linked by it?
Do I miss something simple?


Regards,
Michael

Michael,

<< Now, in ElevateDB I was unable to locate Directory or RemoteDatabase
property. Instead I see that DatabaseName property is matched directly
against the Session configuration database.... So, if I'm understanding it
correctly, if I need to change the actual name of the database on server
(say, I work with two databases Data and DemoData registered on server), I
have to change the DatabaseName property - which will require changing it
for ALL table components, because they are linked by it? Do I miss something
simple? >>

No, you are correct, and I completely missed that.  I might need to
reintroduce another level of abstraction again to get around this.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> No, you are correct, and I completely missed that.  I might need to
> reintroduce another level of abstraction again to get around this.

I would agree that this is definitely needed.  We already store the
connection information in a cenralized database, so having to predefine the
database locations and names on each workstation will be a problem.  We use
a single database name throughout our entire package to handle data access
for the connected location and simply redirect that database connection to
the correct directory to change which database it is connected to, so the
current design of EDB prevents this simple method of changing databases.

--

---------------------------------------
 Terry Swiers
 Millennium Software, LLC
 http://www.1000years.com
 http://www.atrex.com

 Atrex Inventory Control/POS -
    Big business features without spending big business bucks!

Atrex Electronic Support Options:
 Atrex Knowledgebase: http://www.atrex.com/atrexkb.asp
 Email: mailto:support@atrex.com
 Newsgroup: news://news.1000years.com/millennium.atrex
 Fax: 1-925-829-1851
 Phone: 1-925-828-5892 (M-F, 9a-5p Pacific)
 ---------------------------------------