On 7/12/2015 8:07 PM, Adam H. wrote:
> I don't need the new features of EDB in DBISAM. I just need to make
> DBISAM's queries the same for the current features that match EDB to
> allow a migration to occur.
>
> So, if it was possible to leave DBISAM's memory features just 'as is' -
> not implementing any EDB ones, but being able to use SQL to execute that
> is compatible with EDB - then that would allow me to take a year or so
> to slowly work through the projects whilst still providing update
> releases in DBISAM to a point where migrating to EDB would be possible.
>
> It's probably more of a dream than anything else, but if you never ask.

Sounds good but unfortunately it means that Tim needs to support
superset of SQL in DBISAM - both currently working (and stable) DBISAM
4.x and EDB 2.x style.

I'm split on this one - for me the current stability of the DBISAM is
the main benefit. SQL change is a major core rewrite of the engine i
assume.

I personally also prefer things to break doing migration  (i.e. dbisam
to edb)- so sql not working is a feature for me as it makres it lot
easier to track down issues and identify areas of code that might
require re-design also due to the way EDB works (in things other than
pure SQL).

Raul

Adam,

<< So, if it was possible to leave DBISAM's memory features just 'as is' -
not implementing any EDB ones, but being able to use SQL to execute that is
compatible with EDB - then that would allow me to take a year or so to
slowly work through the projects whilst still providing update releases in
DBISAM to a point where migrating to EDB would be possible. >>

I'll see what I can do.  The big problem is trying to justify the resources
when most customers just want DBISAM to "stay the course".

What I could look into doing is finally adding a DBISAM script converter for
DBISAM->EDB.  There's probably a valid reason why I didn't do one yet, and
it probably has to do with some missing pieces of information that can’t be
gleaned directly from the script. But, I can probably just ask the developer
for the missing pieces and be done.

I'm considering adding the joins for UPDATE/DELETE queries in EDB.  It's
something that continuously comes up.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com

Tim

Well, the issue here is no longer about replication but resources from ElevateDB that developers want in DBISAM.

I see the things in a different way. The process of migration from DBISAM to ElevateDB is not so trivial even with tools. But there are some things at least for me that take the process of converting so long and hard.

1) The SQL script feature DBISAM has and ElevateDB has not.
2) A default MEMORY database that DBISAM has and ElevateDB has not. (it can be easily created)
3) The option to edit/change canned results
4) The idea of NULL differente from DBISAM/ElevateDB

Here we are discussing the future and I am giving my opinion and know others have different ones but the Engine component should have a property called DBISAMBehaviour default to false. I think the process is easier than rewrite DBISAM.

Regards
Jose Eduardo Helminsky

Hi Roy,

Not with everything. Just memory tables/scripts. One of the largest
problems I face migrating my applications to EDB are:

--------------------------
select something
into memory\Table1
From somwhere;

select something, somethingelse
into memory\Table2
From memory\table1
inner join mytable on ...
where

--------------------------

The main problem is that I have over a thousand queries that use this -
and not simple like that. Some can be over 200 lines long. Plus the
applications are constantly being enhanced. It's not possible for me to
stop releasing updates to my software to change them all over to EDB,
and then test, etc - as it would take the good part of a year.

If there was some sort of method of achieving the same that was
compatible in both, that would be incredible, and would allow me to
spend a year changing it over and still using it in DBISAM until they
were all done, and tested - and then migration to EDB, this would cut my
downtime to weeks which I could handle.

That's probably a bit more of a dream. I may just be better staying with
DBISAM.

But the short of it is that I don't expect any enhanced SQL features in
DBISAM - just looking for a solution / common ground to bridge two so I
can migrate applications across.

It's most likely not plausible. I'm more brainstorming at the moment -
but if you don't put it out there. Plus just brainstorming there may be
a 3rd option I haven't thought of that someone else might come up with?

Personally I'm happy with DBISAM, but I would like to support and grow
with EDB if it was possible. At present only smaller newer applications
are on EDB. Our largest (95% of our income) is currently with DBISAM and
will probably remain that way unless I can figure out a solution that
will not involve large downtime / migrations to get across.

Cheers

Adam.

Hi Raul,

> I'm split on this one - for me the current stability of the DBISAM is
> the main benefit. SQL change is a major core rewrite of the engine i
> assume.

I can certainly understand. It may not be plausible at all - or require
too much time on Tim's behalf. I'm more brainstorming at the moment (or
dreaming out loud ) - and am definitely open to it not being
practical if it's not.

Cheers

Adam.

Hi Tim,

> I'll see what I can do.  The big problem is trying to justify the
> resources when most customers just want DBISAM to "stay the course".

Thanks for that. I can appreciate what your saying - some times we
request things that are easy to do, and other times things that are
impractical. I have no idea what would be involved or if there was
another way...

> I'm considering adding the joins for UPDATE/DELETE queries in EDB.  It's
> something that continuously comes up.

.... and there's another way.

If EDB could handle scripting the same as DBISAM (I know it would break
the SQL standard - or at least give additional features that are not SQL
standard - that would probably be perfect for our needs).

I think I asked this years ago which is why I was focused on DBISAM
being more compatible with EDB - but it may make a lot more sense to add
additional features to EDB instead if your willing to reconsider.

Cheers

Adam.

Jose

>1) The SQL script feature DBISAM has and ElevateDB has not.

Unless the script uses SELECT INTO this is trivial to implement yourself as a subclassed query, or a called function - I use a function I sling a stringlist at.

>2) A default MEMORY database that DBISAM has and ElevateDB has not. (it can be easily created)

Yup - all my apps have an in-memory database called "Memory"

>3) The option to edit/change canned results

This is more difficult since the solution with currect ElevateDB requires a SELECT INTO - either a temporary table or an in-memory table

>4) The idea of NULL differente from DBISAM/ElevateDB

Hmmm. I subclassed TEDBTable & TEDBQuery to replace all emptystrings with NULLs on posting. I didn't have a lot of queries to bring over so all my WHERE clauses us IS NULL / IS NOT NULL rather than = '' or <> ''

I did it that way rather than following the suggestions of making all string fields default to '' because a) I can use the IS NULL test and b) I can use .Clear in Delphi

Roy Lambert

Tim


>What I could look into doing is finally adding a DBISAM script converter for
>DBISAM->EDB. There's probably a valid reason why I didn't do one yet, and
>it probably has to do with some missing pieces of information that can’t be
>gleaned directly from the script. But, I can probably just ask the developer
>for the missing pieces and be done.

I started one yonks ago but gave up when no-one seemed interested and I couldn't do it as a solo since I needed scripts to work on and people to test them. The lack of interest may be you valid reason. It was certainly mine for stopping. Dunno what happened to the code I'd produced though.


>I'm considering adding the joins for UPDATE/DELETE queries in EDB. It's
>something that continuously comes up.

Yippeeee - now I just have to resurface the mechanisms for using them from long term memory storage.

Roy Lambert

Jose


Actually I forgot IF EXISTS / IF NOT EXISTS

If you've used those they'll need to be stripped out.


Roy Lambert