Adam

>For me the main issue I face is multiple queries and selecting into
>Memory tables, and then doing queries from those memory tables. (You
>should see some of my SQL statements - there very complex

That was one of my prime hatreds. Tim helped with a script to which I simply pass the query and it does the rest. It works and the script takes most of the sting out of the conversion but I still prefer DBISAM's syntax. You'll probably find that the SQL 2012 standard will introduce it

I'd also just got my head round using JOIN in DELETE statements and had to learn a new syntax. It was all very hard on my poor old brain. With my current knowledge I don't think the conversion would have been to bad but with my experience of SQL limited to DBISAM it was tricky on occasions.

I think you two are probably choosing a good approach but I would recommend doing the conversion once you've had some practice using ElevateDB.

Roy Lambert

Can I just clarify this please? Let's say I have two apps, A and B. From your
option 3, I should be able to have each with completely independent setups for
their catalog (config) files yes? So I'd have A run, see there is no catalog, and
create it (presumably EDB allows me to start a new one from code). It could then
set up a database to have the files in a directory that is for A only, and it could
get on with things nicely. Likewise when B turns up, it could be completely
independent.

Does the EDB data manager make it easy to do the reverse coding as DBISAM used to?
And is EDB tolerant of databases being deleted, and allowing the code to re-create
the table? One of my apps uses this a lot...

/Matthew Jones/

Matthew


>Can I just clarify this please? Let's say I have two apps, A and B. From your
>option 3, I should be able to have each with completely independent setups for
>their catalog (config) files yes? So I'd have A run, see there is no catalog, and
>create it (presumably EDB allows me to start a new one from code). It could then
>set up a database to have the files in a directory that is for A only, and it could
>get on with things nicely. Likewise when B turns up, it could be completely
>independent.

Yes - Providing you have set up unique names for the configuration file. Think of the configuration file as the database of databases. It hold information about what databases you have in the app, what users etc. The catalog file (and you can have several to an configuration) holds details about a database and its associated tables. ALL the catalog files will have the same name (or at least I can only see one place in the session to set it).

However if you choose to name all your configuration files matthew.config do not blame me for the catastrophe that will occur.


>Does the EDB data manager make it easy to do the reverse coding as DBISAM used to?

Yes and no Click a couple of buttons and EDBManager will reverse engineer the database. If you want just a table you have to cut'n'paste (Tim has promised - I think - a single table option). There are more elements possible because the indexing's a bit different and you can have things like triggers, functions etc. Also you can't use the table reverse engineer code in isolation. It has to be used in the context of a database.

>And is EDB tolerant of databases being deleted, and allowing the code to re-create
>the table?

This is where we have to be careful with the meaning of words like database. In ElevateDB there is a catalog file which is to all intents and purposes the database. The other files are simply to hold data/indices. ALL the definitions are in the catalog. If you delete the table files at the OS level then ElevateDB will recreate them empty when you first attempt to access them (I use this as a cheat to save me from having to DELETE FROM my tables when importing the live data back into my development system). If you delete the catalog file then having the table files around will do you no good because you can't access them. The best you can do is create a new catalog and (hopefully)  point it at the tables.

Its easy enough to create a system from scratch in code (generally using the reverse engineered code from EBDManager unless you're a masochist).  Its also easy to DROP TABLE and then later on CREATE TABLE. The main thing being to get the context right - ie make sure you're in the right session/database when you do it.


>One of my apps uses this a lot...

Deliberately?

Roy Lambert [Team Elevate]

Gregory,

<< The thing that stops me going furthur with EDB on both occasions is the
deployment of the EDB Config file. I could not find a way to
programmatically deploy the Config file in a multiuser workgroup enviroment.
The only way I can see it being done is to allow the end user to point to
the config file path on a shared network folder from within my app. >>

I already have difficulty guiding some users via email/ web to open their DB
from a network shared folder. This was all that was required in DBISam but
in EDB, I will probably have to help users point to the Config file as well
from all workstations. This could also put off some end-users not to mention
the increased support cost for me. I'm concerned that some of my existing
customers may not want to purchase my new EDB driven product just because of
this additional configuration required on their part. From their point of
view, my new version would be a step back. Most of them won't benefit from
the Unicode support and none of them will benefit from the new SQL support.
>>

A new feature is going into the next 2.03 B14 build that will allow the use
of relative paths for databases, with relative in this case meaning
"relative to the location of the configuration file".  This will allow you
to simply specify the configuration file path, and then have the database
paths all be specified as relative to the absolute path used by the
configuration like this:

TEDBEngine.ConfigPath = m:\myapp

MyDatabase = CREATE DATABASE MyDatabase PATH 'data'

ElevateDB will then look in the m:\myapp\data directory for the MyDatabase
catalog and tables.

--
Tim Young
Elevate Software
www.elevatesoft.com

Gregory,

<< What about in Remote sesssions. In DBISam we only need to specify the
hostname/port or IP address/port to connect to the DBISam server. In EDB, is
the Config file relevant on the client side application as well or only on
the server side ? >>

It's only relevant on the server side and for local sessions on the client
side, and is ignored for remote sessions on the client side.  Just like with
DBISAM.

--
Tim Young
Elevate Software
www.elevatesoft.com

Gregory,

BTW, this excellent feature request was made by Rob Frye.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Roy,

> I think you two are probably choosing a good approach but I would recommend doing the conversion once you've had some practice using ElevateDB.

I would love to do that, but unfortunately I don't believe that will be
possible in my situation. We're talking 300+ queries, with many of them
extremely complex. (I tried the conversion script but the conversion
didn't work - presumably because of their complexity).

These are queries that may have 12 or more queries within them, with
multiple "select into memory" statements, and then other queries
selecting from those with joins to physical tables into other queries, etc.

Some of these took me hours to get right (for just a single query) and
two of these application have taken over 4 years of development - so I
envisage the time it would take to convert these larger applications to
EDB will be too cost prohibited. (Especially when the end client will
notice no difference from a user perspective).

I think my only options are to either keep DBISam for all applications,
or keep DBISam within these older applications and start using EDB for
all future apps.

I think the latter is the better option. (Of course, my fingers are
crossed that maybe one day EDB may introduce some options for "select
into memory" and the like with EDBQueries... but that's very wishfull
thinking.

Cheers

Adam.

Thanks Tim,
Will probably try EDB again for my own internal projects before trying it in
my commercial products.

Regards
Gregory Sebastian

Adam

Without seeing the queries I can only say you're proabably right. I'd guess that anything that mixes DBISAM style scripts and SELECT INTO memory tables is a no go for simple conversion.

Roy Lambert [Team Elevate]

Many thanks Roy. To know that these are all possible gives confidence.

And yes, the support people for one of my apps get a little trigger happy, but the
data in the tables has a lifetime of about 3 minutes, so if it is failing for some
reason they often delete them to clear it all out and my app re-populates and
carries on. Obviously not a common use of a database, but it is a very nice way to
handle massively multi-threaded data access.

/Matthew Jones/