Hi friends:

I´m considering ElevateDB for an application that must handle about 1,000 concurrent remote users, each of them answering about 200 questions in about 1 hour.

The ElevateDB server running in a dedicated computer.
Each user running a program (.EXE) that connect to the Database via the server IP address.

Main requirement is do not use Internet browser,

I really like DBISAM,  years ago i develop a DBISAM C/S (LAN) application for one of my customers (Win98), actually it is running on W7 (not dedicated computer) for 80 users.  

I love the ZERO configuration habilities of DBISAM,

Actually i use Firebird, but i need to only drop the server and the DB, i remember that with DBISAM there was not need for other files (only the .exe and the Database. Im a little confusing reading here about ElevateDB cat file, config file and  have doubts about some "clever" user trying to modify those files and create problems.

I need to know if somebody already use ElevateDB with a big quantity of remote concurrent users (1000 aprox.)
and i need to clarify about the additional files that must be deploy with the final product, i guess that if i buy the Source code versión i can do something to get rid off .ini files but what about the cat file.


Thanks in advance for your kindly advice.

Pitoniso

Sorry I can't comment on the number of users, maximum number I have is closer to 50 than 1000, but I have never had real capacity issues with EDB, of course it depends how you are designing the application and simple issues like the quantity of data in individual queries.

With Client-server install of EDB there is zero install if the EDBSRVR is installed on the server machine & accessed via IP. You only need the EXE, It is just as simple and easy as DBISAM for the user.

The actual mechanics of EDB are more complicated (extra components, extra functionality, extra work...) but honestly to replicate what DBISAM can do you don't have to learn _that_ much more. You will spend time learning to do new stuff ...

Note that with the Replication capability of EDB it is much easier to have multiple servers (for load sharing) and to then have an update process which merges data from the servers from time to time. This would make it possible to scale and work with 1,000s of simultaneous users fairly easily.

Also, there is really no need to worry about the catalog files. They reside on the server, not on the users machine. If someone is in a position to "play around" with your catalog files ... then you are in big trouble, as it would mean that they had total access to your server.

There is the issue that you must guard against SQL injection attacks which might ALTER your catalog remotely, but that is a programming issue general to all databases not just EDB.

Adam Brett wrote:

Also, there is really no need to worry about the catalog files. They reside on the server, not on the users machine. If someone is in a position to "play around" with your catalog files ... then you are in big trouble, as it would mean that they had total access to your server.

There is the issue that you must guard against SQL injection attacks which might ALTER your catalog remotely, but that is a programming issue general to all databases not just EDB.

Adam:

Thanks for your advice, regarding the cat file i understand that if somebody do some funny stuff on the cat file the server may fail.

if the database is encrypted and somebody get the Database files and the cat file to an environment where the ElevateDB software is installed ¿is it possible to access and/or modify the Database data or structure (i mean use DDL and/or DML)?.

my concern is about the privacy of the database, if the cat file was corrupted the consecuences will be obvious and the worst thing will be restore the cat file and the database and re-process all data, but ¿is there a chance of using the cat file in an other ElevateDb environment and altering the data or rules (triggers,Procedures) of the database?

thanks again for your help.

>Thanks for your advice, regarding the cat file i understand that if somebody do some funny stuff on the cat file the server may fail.<

The Catalog file can be encrypted as well.

>if the database is encrypted and somebody get the Database files and the cat file to an environment where the ElevateDB software is installed ¿is it possible to access and/or modify the Database data or structure (i mean use DDL and/or DML)?.<

No, not if the database and catalog are encrypted.

>my concern is about the privacy of the database, if the cat file was corrupted the consecuences will be obvious and the worst thing will be restore the cat file and the database and re-process all data, but ¿is there a chance of using the cat file in an other ElevateDb environment and altering the data or rules (triggers,Procedures) of the database?<

Only if someone knows the encryption password for the Catalog (see below).  The catalog stores the table, view, definitions etc. and is matched to the data files. You cannot mix the catalog file from another database and expect everything will work for long. The catalog file must always be backed up with the data files. Encrypting the catalog file with a unique password will solve the problem.

The only file that cannot be encrypted is the EDBSrvr.ini file which has the settings for the EDB server. It DOES have the Signature value that is used to encrypt the communications between the client and the server and could be a security risk. This is the same value that is used to encrypt the catalog file (big oops!).

But since you have the source code to the EDBSrve.exe, you could modify the code so stores the signature encrypted in the .ini file and decrypts it in memory when the .ini file is loaded. I'm not sure why Tim didn't think of this already.  Of course you need to find a way to get the decryption password to the EDBSrvr.exe, maybe through a secure link to another server like a web service by passing the MAC Id of computer hosting the EDBSrvr. Of course if you did this, then you wouldn't need to encrypt the signature in the ini file, but instead request the signature directly from a web service. This creates a bit of a paradox (excuse the pun).

Barry

Barry,

<< The only file that cannot be encrypted is the EDBSrvr.ini file which has
the settings for the EDB server. It DOES have the Signature value that is
used to encrypt the communications between the client and the server and
could be a security risk. This is the same value that is used to encrypt the
catalog file (big oops!). >>

Just a clarification for the lurkers - Signature here means "encryption
password", not the "engine signature" feature.

<< But since you have the source code to the EDBSrve.exe, you could modify
the code so stores the signature encrypted in the .ini file and decrypts it
in memory when the .ini file is loaded. I'm not sure why Tim didn't think of
this already. >>

There's going to be some updates to the password handling at some point.
I'm just trying to find the ideal release to do it, because it will be
somewhat disruptive.

Tim Young
Elevate Software
www.elevatesoft.com

>>There's going to be some updates to the password handling at some point.
>>I'm just trying to find the ideal release to do it, because it will be
>>somewhat disruptive.

Not sure I like the sound of that ... are you trying to soften us up Tim??

My first reaction was "oh shit". My second was we really need a Richter scale for software changes. So is "somewhat disruptive" nearer to 1 or 10?

Roy Lambert

Adam,

<< Not sure I like the sound of that ... are you trying to soften us up
Tim?? >>

No, nothing that bad - just a breaking change that will affect your code, so
it needs to happen during a minor release instead of a build.

Tim Young
Elevate Software
www.elevatesoft.com

Dear friends:
Do not tag me as a lurker, i pledge on my projects,i post here for help on a descicion about investment, i checked my oldest project with DBISAM and it is 2.4 version,. oldie but  working on W7.

I really love DBISAM, my priviledge is to ask, but not to bypass my development efforts.