1. I think there needs to be a forum devoted to this topic.
2. I have found this process frustrating and perplexing and occasionally annoying.
3. With DBISAM, I used to point my application at a directory and it would treat it like a database, and grab all the tables from there and just work.

I am trying to replicate this using ElevateDB (rightly or wrongly this seems a moot point when you consider...)

If I develop an app in
\some app\

and store the data tables in
\some app\data

it would make sense to point the engine component at that directory so it finds the files/tables. This is set in the config file, and the ConfigPath is set for the engine.

If a user then installs the application to
\some install dir\

and the data files hence end up in
\some install dir\data

am I right in my thinking, that the only way I can get the application to "find" the data files is by updating the database, changing the path to point to the new data location?

If so, this seems an incredibly roundabout, annoying, ridiculous even, way of doing things.

</rant>

As in:

ALTER DATABASE <Name>
PATH \some install dir\data

The search function works!

http://www.elevatesoft.com/forums?action=view&category=edb&id=edb_general&page=1&msg=11577#11577

Aaron


Congratulations and welcome. I made the change a couple of years ago now and at the time I also found it highly frustrating. I still do when I want to do a quick test which in the DBISAM days would have meant drop a TDBISAMTable on the form and point at the directory which now requires TEDBEngine, TEDBSession, TEDBDatabase, TEDBTable and all hooking up properly. But there are a large number of positives for the negatives (mind you if Tim keeps back porting them to DBISAM I may have to revert <vbg>).

How rough or smooth the transition is depends on which version of DBISAM you're porting from, how much you use queries vs tables, how you handled empty string vs nulls and a few other factors. An advantage you do have (as you've discovered) is that a lot of the questions have already been asked and answered in these newsgroups if only you can find the right search terms to drag them out.

Roy Lambert [Team Elevate]

Aaron,

<<1. I think there needs to be a forum devoted to this topic.
2. I have found this process frustrating and perplexing and occasionally
annoying.
3. With DBISAM, I used to point my application at a directory and it would
treat it like a database, and grab all the tables from there and just work.
>>

I know I say this all of the time here, but I think it bears repeating
again.  ElevateDB is *not* DBISAM.  It is not supposed to be like DBISAM,
and was intentionally designed to be different than DBISAM, especially in
this respect.  You'll find out how much better the ElevateDB design is, once
you start using it for a while.

The easiest way to get your head around ElevateDB is to do this:

1) Forget about the configuration path for a second in terms of how
databases are located.
2) Think of the CREATE/ALTER DATABASE statements as the same thing as
modifying the TDBISAMDatabase.Directory property.  The only difference is
that one saves its settings on disk (EDB - configuration file), and one
simply has the setting in the application in a component.
3) The configuration path is simply a pointer to the location where EDB
stores the database path settings (and users, roles, stores, and jobs).

The benefit to your application is that you always simply use MyDatabase as
a logical name everywhere - in SQL, components, code, etc.   You even use
the same name for local and remote databases.   And, if you change the
location of the database using CREATE/ALTER DATABASE statements, *nothing*
in your application needs to be changed.   This is *not* true with DBISAM,
which always requires some form of application change if the database
directory changes.  Unless, of course, your DBISAM application is storing
the database path somewhere and dynamically setting the database path when
the application starts up.  ElevateDB simply does this part *for you*.

--
Tim Young
Elevate Software
www.elevatesoft.com

I don't think it needs repeating, it's bleedingly obvious, Tim

If you have a config file already created, filled with users and roles and all that good stuff, what's the difference between having to set the path of the ElevateDB config file vs having to set the path of the DBISAM database?

It's kinda rhetorical - it's clear you have no interest in making the 2 databases work the same way. I forgot for a second the path to the config file, as you requested. But my version control workflow, of copying an entire application directory and renaming it to Version n+1 requires me to

* change the config file location in EDB manager
* change the config file location in EDBEngine

each time I version the app, and I need code in the start up of the application that checks current db path, comparing it to current application path, and updating as required.

In DBISAM, well, I would just always set the path to {app}\data.

I realise you are looking to improve the db, and needed them to be different. This is a workflow I am comfortable with, and it works well enough for me. I also recognise I am only one, very old and crusty customer of yours.

This is not a rant now, but a bit more background on where I am coming from. I just migrated to D2010 from D7, and none of the 3rd party controls I had been using worked, so my rant above is the culmination of a week of pulling my hair out, no offense intended.

Aaron


If you want to see some rants search for my old posts. When I did the transition I was busy re-writing a major app and I decided to switch to using TMS and ElevateDB part way through. I'm sticking with ElevateDB but looking at dropping TMS (or at least parts of their component set).

Roy Lambert

>>If you want to see some rants search for my old posts. When I did the transition I was busy re-writing a major app and I decided to switch to using TMS and ElevateDB part way through. I'm sticking with ElevateDB but looking at dropping TMS (or at least parts of their component set).

While I have TMS as well, It's always been hit and miss for stability.  And miss for documentation.  I've really liked the work done by DevExpress and their stuff works nicely with ElevateDB.

Lance,

> I've really liked the work done by DevExpress and their stuff works nicely
> with ElevateDB.

I'll second the recommendation for the DevExpress components.  Very good
components, stable, well documented, and they have great support.

--

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

 The Atrex 13 beta is now available.
 Visit http://v13beta.atrex.com for more information.

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)
 ---------------------------------------