Hi.
I dropped support for DBISAM when I purchased EDB.
Having decided that I simply can't get on with EDB (sorry Tim, I'm sure
it's my own fault). I'd like to re-sign up for DBISAM support. How does
one upgrade from DBISAM v4 CS with source, without support, to the same
thing with the support?

--
Regards
Roj Ash

Roj


Are there any specific issues that those of us who have been through the pain barrier can help with? I know how I felt when I was in the process of converting and I nearly came to the same decision as you several times. There are sufficient advantages ElevateDB has over DBISAM (even back then) to keep me trying.


Roy Lambert

Roj,

I agree with Roy. I had a hard time getting my head around the
configuration file and catalog. I have learned to adapt and overcome
while porting a *large* project (decided to jump in with both feet)
from DBISAM v4.x to ElevateDB. I am glad that I did. Still working on
the porting and making changes in the app itself but EDB really is an
awesome product.

There are still a few things I am fuzzy about (I write C/S apps and am
fuzzier about the local sie of EDB), but the EDB manual and EDB SQL
manual are well written and these newsgroups have helped tremendously.
I believe Roy writes more on the "local" side.

To answer your question, simply purchase a support plan for DBISAM from
the elevatesoft.com website. If you have any problems, contact Sam in
sales and she will help you out. Their support is awesome, as you
probably are aware.

--
Jan


Roj Ash wrote:

> I dropped support for DBISAM when I purchased EDB.
> Having decided that I simply can't get on with EDB (sorry Tim, I'm
> sure it's my own fault). I'd like to re-sign up for DBISAM support.
> How does one upgrade from DBISAM v4 CS with source, without support,
> to the same thing with the support?

Roj,

<< I dropped support for DBISAM when I purchased EDB. Having decided that I
simply can't get on with EDB (sorry Tim, I'm sure it's my own fault). I'd
like to re-sign up for DBISAM support. How does one upgrade from DBISAM v4
CS with source, without support, to the same thing with the support? >>

You would simply need to purchase a new support plan, if your current
support plan is expired.  You can check this, and order a new support plan,
here:

http://www.elevatesoft.com/plans?category=dbisam

Also, if you want to revisit the ElevateDB issues that you're having, you're
always welcome to phone us here and I'll help walk you through any issues
that you may be having trouble with.  It's not an uncommon issue for DBISAM
customers - many have trouble making the switch.  However, once you "get"
the idea of how ElevateDB is designed, everything will pop into place.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Roj,
>
> << I dropped support for DBISAM when I purchased EDB. Having decided
> that I simply can't get on with EDB (sorry Tim, I'm sure it's my own
> fault). I'd like to re-sign up for DBISAM support. How does one
> upgrade from DBISAM v4 CS with source, without support, to the same
> thing with the support? >>
>
> You would simply need to purchase a new support plan, if your current
> support plan is expired.  You can check this, and order a new support
> plan, here:
>
> http://www.elevatesoft.com/plans?category=dbisam
>
> Also, if you want to revisit the ElevateDB issues that you're having,
> you're always welcome to phone us here and I'll help walk you through
> any issues that you may be having trouble with.  It's not an uncommon
> issue for DBISAM customers - many have trouble making the switch.
> However, once you "get" the idea of how ElevateDB is designed,
> everything will pop into place.

Thanks for the info (I just couldn't find the "Purchase a support plan"
option - duh).

Thanks also for the offers of help, but my most profitable jobs are
adding bells and whistles to the software of customers who've been
using DBISAM for years and years. It seems to me that converting to EDB
would need a fundamental redsign of the programs they are currently
using, and in the current economic climate, persuading them to go for a
total rewrite is just not an option.

I admit that I was also frightened off somewhat in the early days by
the continual updates rectifying "major problems".

The unique advantages of DBISAM over the BDE and other alternatives
were immediately apparent to most developers - and their customers.
What's more, converting an application from (say) Paradox to DBISAM was
almost trivial.

EDB may well have many advantages over DBISAM, but they are not (to my
users) instantly apparent, and the uniqueness of EDB compared to its
perceived competition is not so clear.


--
Roj

Hi Roy,
<<Are there any specific issues that those of us who have been through the
pain barrier can help with?>>
Hope you don't mind if I jump in and take you up on your kind offer.  I
could do with a little help

I've tried migrating my DBISam apps to EDB twice already. The first time was
about 2-3 years ago. Then most recently only a few weeks ago. I even
purchased ElevateDB when it was on promotion a few weeks ago. The main draw
for me for EDB is the Unicode support and the much improved SQL support.

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.

If anyone can give me a solution to this, I'll gladly give the migration to
EDB another try when i next upgrade my apps. Basically I need to
transparently deploy the EDB Config file on the end users workgroup
enviroment such that the end-user does not have to bother with it. While
single user is not a problem, how to others deploy their config file for
local/multiuser sessions and remote sessions ?

Thanks
Gregory Sebastian

Gregory


It depends to some degree on your strategy on the relationship between the config file and the location of the databases (ie the table files) The main thing that seems to give problems is that ElevateDB has broken the 1:1 relationship between directory and databases. In one respect its better in others a bloody nuisance. Where its better is when you have multiple databases as part of one system and you oly need to point at one config file to handle them all.


First point is to use UNC paths all the time and never use local / mapped paths. That way lies madness.

Second, if you're deploying single database applications then do one of the following:

1. dump the config file in with the data (not really recommended but its probably the easiest)
2. have a simple database structure eg ..\congif\data that way when you've found the config file you've found the data.
3. since you can search for a single file then
    a) use a unique config file name for each app
    b) build in a bit of code to go off searching for that file and set up the path automagically (iterating network shares is fun but doable)

The biggest thing to get used to is that ALL users have to use the same path and the fact that you can't change the database information whilst its in use.

Roy Lambert [Team Elevate]

Thanks Roy, will take on board your points.

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 ?

Regards
Gregory Sebastian

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

Should be the same.

<<In EDB, is
the Config file relevant on the client side application as well or only on
the server side ?>>

I use ElevateDB in f/s mode not c/s so no direct experience BUT I can say that the config file rules everywhere.

In c/s mode then providing you never want to access the database directly over the LAN you should be safe with local paths.

Roy Lambert [Team Elevate]

Hi Roj,

> Thanks also for the offers of help, but my most profitable jobs are
> adding bells and whistles to the software of customers who've been
> using DBISAM for years and years. It seems to me that converting to EDB
> would need a fundamental redsign of the programs they are currently
> using, and in the current economic climate, persuading them to go for a
> total rewrite is just not an option.

I am in a similar boat to you. I have a couple of very large
applications that will unfortunately take too much time and cost to port
to EDB.

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

I have decided to stay with DBISam for my main applications. (Which are
my existing ones).

Any future applications I'm writing I'm attempting to do with EDB. These
are the smaller applications for me anyway - which give me some time to
learn more about EDB before doing a new large application if one comes
my way.

I envisage that my existing large applications may be around for another
10 years or more. (And I'm hoping that DBISam will continue to run and
support new operating systems for at least that amound of time)

However - I believe the prudent course of action is to design any new
applications on a framework that is more likely to be supported and
updated into the future. (aka EDB).

Don't be put off using EDB for new applications, but don't be put off by
the fact that you still need to use DBISam in your older applicaitons
either. There's a large group of us still using DBISam and I dare say
it'll be around for some time.


> EDB may well have many advantages over DBISAM, but they are not (to my
> users) instantly apparent, and the uniqueness of EDB compared to its
> perceived competition is not so clear.

I would agree with you here. There are advantages with EDB but for many
DBISam more than meets the criteria required. (And is easier to
implement for many).

It's my understanding that EDB isn't a replacement for DBISam but that
it's the next 'level' which the current DBISam architecture couldn't
support. (Stored Procs, Triggers, etc)... and that DBISam will remain
supported for some time - but efforts for new features are going to be
directed at EDB instead.

But then again, you can't improve on perfection, so there's no point
trying to add to DBISam anyway. <VBG>

Cheers

Adam.