Hello,
  Is it an easy way to "convert" an non-encrypted database and catalog
  to encrypted ?

  Also, is it possible to add our own custom encryption ? (and into EDB
  Manager)

Thank you

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Michael,

<< Is it an easy way to "convert" an non-encrypted database and catalog to
encrypted ? >>

See here:

http://www.elevatesoft.com/newsgrp?action=openmsg&group=16&msg=11208&page=1#msg11208

<< Also, is it possible to add our own custom encryption ? (and into EDB
Manager) >>

Yes, but it will need to be a block cipher, and will need to be added to the
edbcommon.pas unit.  Also, you'll need to constantly recompile the EDB
Manager and the EDB Server in order to have them use the new encryption.

--
Tim Young
Elevate Software
www.elevatesoft.com

Dear Tim,

> << Is it an easy way to "convert" an non-encrypted database and catalog to
> encrypted ? >>
>
> See here:
>
> http://www.elevatesoft.com/newsgrp?action=openmsg&group=16&msg=11208&page=1#msg11208

> You're also going to need to recreate any tables that were marked as
> encrypted (.edbtbl and .edbidx, and, optionally, .edbblb and .edbpbl
> files).

But i need to export and import the data too right ?
Could you please add an easy way to do that into your todo list ?

I'm starting to think to jump to DBISAM ... It was so damn
easier than EDB ...

> << Also, is it possible to add our own custom encryption ? (and into EDB
> Manager) >>
>
> Yes, but it will need to be a block cipher, and will need to be added to the
> edbcommon.pas unit.  Also, you'll need to constantly recompile the EDB
> Manager and the EDB Server in order to have them use the new encryption.

Will be possible to do that in the future without needing modifying
the source code in both EDB & Manager ? (Like a Plugin)

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Michael,

<< But i need to export and import the data too right ? >>

Yes, absolutely.

<< Could you please add an easy way to do that into your todo list ? >>

I'll see what I can do.

<< I'm starting to think to jump to DBISAM ... It was so damn easier than
EDB ... >>

DBISAM didn't just start out as 4.29 Build 2.  I took some time (8-9 years)
to get the kinks ironed out.  You don't seem to be willing to give ElevateDB
the same time to mature, but ElevateDB is much, more more stable, with much
better performance and features, than DBISAM at the same stage in its
lifespan.

<< Will be possible to do that in the future without needing modifying the
source code in both EDB & Manager ? (Like a Plugin) >>

Perhaps, but it isn't an option that is very high on the list.

--
Tim Young
Elevate Software
www.elevatesoft.com

Dear Tim,

> DBISAM didn't just start out as 4.29 Build 2.  I took some time (8-9 years)
> to get the kinks ironed out.  You don't seem to be willing to give ElevateDB
> the same time to mature, but ElevateDB is much, more more stable, with much
> better performance and features, than DBISAM at the same stage in its
> lifespan.

Well, You already knew what DBISAM was capable to do when you developed
Elevate DB ... Currently EDB has only more features (DBISAM is stable!)
and without an accurate scrollbar for the moment (which DBISAM had and
we discussed about it so no need to answer) and as far for performance i
can't see any difference at least for my projects. (unless you have
benchmarks ?)

> << Will be possible to do that in the future without needing modifying the
> source code in both EDB & Manager ? (Like a Plugin) >>
>
> Perhaps, but it isn't an option that is very high on the list.

I'm curious to see what's "On Top" on that list!

Don't get me wrong but i really see that EDB need a lot more time to
get into the level that it can replace "DBISAM".

Anyway, it seems that i took the wrong direction to moving to edb.
(Sorry, my personal opinion ...)

So I'm thinking renewing my DBISAM support.

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Michael,

<< Well, You already knew what DBISAM was capable to do when you developed
Elevate DB ... Currently EDB has only more features (DBISAM is stable!) >>

ElevateDB is extremely stable, and has been for some time.  The last build 7
was a little rocky due to some performance improvements that broke a couple
of important features, but that's what happens sometimes when a product is
being actively developed and improved upon.

<< and without an accurate scrollbar for the moment (which DBISAM had and we
discussed about it so no need to answer) and as far for performance i can't
see any difference at least for my projects. (unless you have benchmarks ?)
>>

Try ElevateDB and DBISAM on a table with a 500 thousand or more rows, and
you'll see the difference.

<< Don't get me wrong but i really see that EDB need a lot more time to get
into the level that it can replace "DBISAM". >>

Nonsense.  ElevateDB has more functionality now than DBISAM ever had.  The
fact that it doesn't do things the "DBISAM way" is intentional - I didn't
*want* it to do certain things the way that DBISAM does them.  Otherwise, I
would have called it DBISAM 5 and released it as such.

--
Tim Young
Elevate Software
www.elevatesoft.com

Dear Tim,

> << Well, You already knew what DBISAM was capable to do when you developed
> Elevate DB ... Currently EDB has only more features (DBISAM is stable!) >>
>
> ElevateDB is extremely stable, and has been for some time.  

Did i say it wasn't ? I said it was as DBISAM is too!

> The last build 7 was a little rocky due to some performance improvements
> that broke a couple of important features, but that's what happens
> sometimes when a product is being actively developed and improved upon.

That's why i insist on keeping older builds on the website ...

> << and without an accurate scrollbar for the moment (which DBISAM had and we
> discussed about it so no need to answer) and as far for performance i can't
> see any difference at least for my projects. (unless you have benchmarks ?)
>  >>
>
> Try ElevateDB and DBISAM on a table with a 500 thousand or more rows, and
> you'll see the difference.

Well, as i can see bulk adding records to EDB slows as DBISAM did ...
(The reason of removing statistics right ?)

Now, i don't have 500 thousand records to test but i might have
within 2010 ...

Ole could do that but he moved to Nexus

> << Don't get me wrong but i really see that EDB need a lot more time to get
> into the level that it can replace "DBISAM". >>
>
> Nonsense.  ElevateDB has more functionality now than DBISAM ever had.  

Yes, but it doesn't have the "easy of use" of DBISAM had ...
So it still lacks of some pretty handy DBISAM functionality.

> The fact that it doesn't do things the "DBISAM way" is intentional - I didn't
> *want* it to do certain things the way that DBISAM does them.  Otherwise, I
> would have called it DBISAM 5 and released it as such.

Of course ... But since your majority of your customers are
coming from DBISAM, you should make the things more "compatible".

Eg, in DBISAM i could alter a field name and it altered the index.
In EDB i must first remove the index and then Alter field and readd
the index.

Do you imagine doing that on a lot of fields of many tables ?
The examples can go on and on ...

Why do you think that many of your customers decided not to move
to EDB yet ? ...

Just discussing ...

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Charalampos

>> Try ElevateDB and DBISAM on a table with a 500 thousand or more rows, and
>> you'll see the difference.
>
>Well, as i can see bulk adding records to EDB slows as DBISAM did ...
>(The reason of removing statistics right ?)
>
>Now, i don't have 500 thousand records to test but i might have
>within 2010 ...

You could build a test bed easy enough

>Yes, but it doesn't have the "easy of use" of DBISAM had ...
>So it still lacks of some pretty handy DBISAM functionality.

Here I still agree with you, but things are improving. Tim just did too good a job on DBISAM. But also consider "ease of use" often equates with familiarity and you're very familiar with DBISAM as I was when I switched to ElevateDB.

Do I regret switching? Occasionally, when I hit a block on something I knew how to do in DBISAM but not in ElevateDB, or where something works differently in ElevateDB (I'm still finding them after a couple of years . In general ElevateDB has a lot more capability that I do appreciate.

Would I switch back? Probably not.

Would I have switched if I knew in advance how much effort it would take? Again probably not. One of my main motivators was improved performance for full text indexing so I might have done. Who knows?

>Eg, in DBISAM i could alter a field name and it altered the index.
>In EDB i must first remove the index and then Alter field and readd
>the index.

You didn't used to be able to but now it works like in DBISAM, and hopefully triggers will be added in soon (if they haven't already and I haven't noticed).

>Do you imagine doing that on a lot of fields of many tables ?
>The examples can go on and on ...
>
>Why do you think that many of your customers decided not to move
>to EDB yet ? ...

One thing to remember is that ElevateDB is NOT an upgrade to DBISAM but a totally different product. Its why Tim was (relatively) easily persuaded to continue DBISAM.

More ease of use features are arriving now the functionality is there, and more will be, especially if many people ask for a specific one eg double clicking to open tables in EDBManager.

Roy Lambert

IMHO, I think ElevateDB is excellent.  *Real* stored procedures, functions, triggers, constraints and jobs make development much easier for me because I
can build a lot of functionality into the database.  And when the messaging layer is introduced it will be even better.

My applications don't need to know a lot about the data or most of the business rules as these are handled by the database.  All they need to do is call the
appropriate stored procedures to add, view, edit or delete data or otherwise process information.  

For example, with one of my applications the user login accounts can have optional expiry dates.  When a user attempts to login, the application simply
passes their username and password to the database.  The database then checks to see if their username and password are valid, if their login account is
enabled or disabled, if the account has an expiry date and if so, if the date has passed.  The user is then either logged in, or not.  If not, the database
passes a response back to the application giving it a reason why the user can't login.

The thing I like about this is that the database becomes a black box.  The application doesn't know and doesn't care about what's happening inside the
database.  With DBISAM (which I still use for small, desktop applications), my applications are more involved in handling the data.  All of the database
functionality is in code and dynamically generated queries.  This can sometimes make it difficult to debug.

With ElevateDB I can separate all of the database stuff out.  Basically I write stored procedures for just about everything.  Once I have a stored procedure
working correctly I don't have to worry about it anymore.  If there is a problem with data in the application, I can go straight to the stored procedure,
execute it directly, and make sure it's doing the right thing.  If it is then I know the problem is in my application.

Perhaps working with Oracle and SQL Server have helped with getting my head around this, I don't know.  Most of the large Government systems I have
been involved with work like this.  A lot of intelligence and functionality is built into the database.

I guess it all depends on what the purpose of the application is.  Personally, I think DBISAM is suited to smaller applications (eg. desktop applications) and
ElevateDB is better for larger systems that could potentially have a lot of users (eg. network applications).  Mind you, I have a DBISAM application with
well over 100 users on some sites running happily, but this will be replaced with an ElevateDB app.

I'm probably preaching to the converted but thought I'd just give my 2 cents worth.

Regards,

Steve

Steve


Something I've given a lot of thought to over the years is the model used for databases. These range from 1 app with 1 user accessing 1 database (in the extreme 1 table) through 1 app with many users accessing 1 database to many apps with many users accessing 1 database with a side trip of 1 app with many users accessing many databases of the same structure.

For each of these models there is an optimum place to store the program logic inclusive of "business rules" (a ghastly term invented by consultants).

In my view its only in the many apps with many users accessing 1 database case where the optimum is storing the logic in the database. At the other end of the spectrum, 1 app with 1 user accessing 1 database, the optimum is all logic in the program. In between it gets fuzzy, some stuff is better in the database, some in the program.

This

<<Perhaps working with Oracle and SQL Server have helped with getting my head around this, I don't know.  Most of the large Government systems I have been involved with work like this.  A lot of intelligence and functionality is built into the database.>>

generally means operating at one end of the spectrum. But I must take exception with your use of the word "intelligence" in relation to government IT.

Roy Lambert