Alan


Strange, it does for me.

Roy Lambert

Alan

>In DBISAM, you could just get the application's path and then set the path
>to the database and connect. It didn't matter what drive it was on.

Oh yes it did!!!!!!

If your data was in D:\fred\bert and you set the path to C:\fred\bert you won't get very far

I think you're getting confused because you could use relative paths.

Roy Lambert

No, what I'm saying is that at the startup of a DBISAM program, you could
simply get the EXE path, set the database path, (or add '\Data' if you
wanted to use a subdirectory), and connect. So it didn't matter where you
copied the program to, it would always work if the tables were there.

"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message
news:6BC2EFA3-D2C7-47BD-8245-F744C6B54664@news.elevatesoft.com...
> Alan
>
>>In DBISAM, you could just get the application's path and then set the path
>>to the database and connect. It didn't matter what drive it was on.
>
> Oh yes it did!!!!!!
>
> If your data was in D:\fred\bert and you set the path to C:\fred\bert you
> won't get very far
>
> I think you're getting confused because you could use relative paths.
>
> Roy Lambert

Alan

>No, what I'm saying is that at the startup of a DBISAM program, you could
>simply get the EXE path, set the database path, (or add '\Data' if you
>wanted to use a subdirectory), and connect. So it didn't matter where you
>copied the program to, it would always work if the tables were there.

Its almost the same with ElevateDB. The way I look at it the main change is the configuration file. For a lot of developers/users with a single app that is a bit of overkill. It will be of benefit when you're running several ElevateDB apps on one site (on one server - client or file).

I think part of the problem is Tim has to make it as easy as possible for users of other sql databases to transfer to using ElevateDB but that has the consequence of making it more "difficult" for us died in the wool DBISAMers.

Standard rock and hard place stuff.

Roy Lambert

"Alan Questell" <alanq@pinehurst.net> wrote in message
news:07EA1867-9A27-4B01-ADF1-06D710519F0F@news.elevatesoft.com...
> Although I'm doing this, the application still tries to access the data
> subdirectory in the development directory when I move the EXE to another
> location:

Our application now goes through these steps at startup (skipping remaining
steps in the group if successful):

a1. look for the cfg file in the folder where our setup installs it (all
users app folder, for example)
a2. get the path to the cfg from an ini file in the same folder
a3. ask the user where the cfg is.

So, this allows the user to move the cfg file (for example to a network
location), then tell us where it is. We then put the path in the ini file,
and the next time it gets found in step a2. They can move again by deleting
the ini file.

Once we have the cfg file, we locate the database as follows:

b1. get the path from a file called 'alias.ini' (I use this during
development to make it easy to switch test database)
b2. get the path from the cfg file,
b3. look where the setup install the database,
b4. ask the user where the database is,

If the db path comes from b1, b3 or b4, we do a DROP DATABASE, followed by a
CREATE DATABASE with the new path. The next time the app is run, b2 kicks in
(unless b1 goes first).

RoyJ

On 5/22/07 8:03 AM, in article
EFE70CD4-7114-436A-8642-E503D50A3C52@news.elevatesoft.com, "Alan Questell"
<alanq@pinehurst.net> wrote:

> I'm using ElevateDB, so it's a different issue.

I know.  I thought it still may help.

"Royke" <royke@canada.com> wrote in message
news:8862999C-3358-47D2-B77D-C6B783DF168D@news.elevatesoft.com...
> "Alan Questell" <alanq@pinehurst.net> wrote in message
> news:07EA1867-9A27-4B01-ADF1-06D710519F0F@news.elevatesoft.com...
>> Although I'm doing this, the application still tries to access the data
>> subdirectory in the development directory when I move the EXE to another
>> location:
>
> Our application now goes through these steps at startup (skipping
> remaining steps in the group if successful):
>
> a1. look for the cfg file in the folder where our setup installs it (all
> users app folder, for example)
> a2. get the path to the cfg from an ini file in the same folder
> a3. ask the user where the cfg is.
>
> So, this allows the user to move the cfg file (for example to a network
> location), then tell us where it is. We then put the path in the ini file,
> and the next time it gets found in step a2. They can move again by
> deleting the ini file.
>
> Once we have the cfg file, we locate the database as follows:
>
> b1. get the path from a file called 'alias.ini' (I use this during
> development to make it easy to switch test database)
> b2. get the path from the cfg file,
> b3. look where the setup install the database,
> b4. ask the user where the database is,
>
> If the db path comes from b1, b3 or b4, we do a DROP DATABASE, followed by
> a CREATE DATABASE with the new path. The next time the app is run, b2
> kicks in (unless b1 goes first).
>

b1: we keep the alias.in in the folder of the exe.
b3 exists so that we can ship a cfg file and database independently (no need
for the db path to be correct in the original shipped cfg).

RoyJ

Alan,

<< I'd seen where he recreated the database but I thought he was just making
sure that they existed, but I was hoping that you could just install with
empty tables and get the path at runtime as we did with DBISAM. >>

You can, but you have to make sure that the database definition for the
database in the configuration matches what you have on disk.  You can do
this by querying the Configuration database to see if the database exists,
and if so, that the path for the database is correct.  If it isn't, then you
can use these statements to fix the problem:

DROP DATABASE MyDatabase KEEP CONTENTS

CREATE DATABASE MyDatabase PATH 'Put the proper path here'

<< What's the advantage of this mechanism? >>

Try updating an application that has database path names in every single
SELECT statement's FROM clause and you'll find out rather quickly.

<< There's one big disadvantage; you can't just take an application on a
jump drive, stick it in any computer, and run it. Unless by chance, it's
assigned the same drive letter as the development machine. >>

Why do you say this ?  None of the paths in EDB are hard-coded - they all
can be modified easily at runtime just like DBISAM.

<< In that case, what happens if the tables are there and I try to recreate
them? And why should I need to recreate them if they're already there? >>

If you simply need empty tables, then don't even ship tables with your
application.  Just ship the EDBDatabase.EDBCat, put it in the database
directory, and then start using the database.  EDB will automatically create
the physical table files as necessary.  Remember, the existence of the table
files does *not* determine if the table exists - the table only exists to
EDB if it is defined in the database catalog.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< I think part of the problem is Tim has to make it as easy as possible for
users of other sql databases to transfer to using ElevateDB but that has the
consequence of making it more "difficult" for us died in the wool DBISAMers.
>>

Yes, that is one reason.  Another reason for the way EDB is designed is that
once you decide to go with RI and other intra-table dependencies, you have
to jump in with both feet and do the database catalog, user security, etc.
stuff.  All of these things are so intertwined that it doesn't make sense to
do one without the other(s).  Plus, if you want to do a real SQL 2003
standard SQL implementation, you have to have all of these things.  It's
kind of an "in for a penny, in for a pound" type of situation.

--
Tim Young
Elevate Software
www.elevatesoft.com

> Why do you say this ?  None of the paths in EDB are hard-coded - they all
> can be modified easily at runtime just like DBISAM.

'Cause I don't know what I'm talking about?

I understand what's going on now. It was the DROP and then CREATE with the
new path I was missing.