![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 10 of 10 total |
![]() |
Sat, Oct 29 2011 1:20 PM | Permanent Link |
Dominique Willems | DBISAM 4 is awesome. It does absolutely everything I desire admirably.
Except one thing. Unicode. I'm launching into a new project that does require Unicode. So there aren't that many other options out there (in Elevate world,that is). ![]() I need to know the following things about ElevateDB, maybe from developers who also have experience with DBISAM 3/4: 1) do you need to deploy any files along with a virgin setup or can they call be created by the .EXE on first run? 2) did you ever notice any speed difference with DBISAM? 3) I won't be needing any client/server stuff; just plain old local DB, and won't even be using any SQL. Most of the DB will be mapped onto an Object Persistence Layer and most data will be manipulated right there. Okay, not really a question here, just inviting any comments wrt ElevateDB advantages; 4) robustness will be a main issue (as always, really). Has anyone noticed any changes compared to DBISAM? How do repairs work? Faster? Never any issues? Always solved the problem? (I just got a DBISAM 3-using customer who had a power failure -- damage to one table was irreparable) Many thanks for all opinions. Cheers, Dom |
Sat, Oct 29 2011 7:06 PM | Permanent Link |
Fernando Dias ![]() | Dom,
> 1) do you need to deploy any files along with a virgin setup or can > they call be created by the .EXE on first run? No, you can create everything on first run if you wish. > 2) did you ever notice any speed difference with DBISAM? Yes. ElevateDB is in genreal faster than DBISAM, and the difference is even bigger with large tables. > 3) I won't be needing any client/server stuff; just plain old local DB, > and won't even be using any SQL. One of the differences between DBISAM and ElevateDB is the way you create database objects. You are going to use SQL to create the database and the database objects instead of the component methods, but thats pretty simple, using TEDBSession.Execute, for example : EDBSession1.Execute('CREATE DATABASE "MyDatabase1" PATH ''c:\MyData'' '); as well as TEDBBatabase.Execute to create the database objects: EDBDatabase1.Execute('CREATE TABLE "Tbl1" (X INTEGER) '); > 4) robustness will be a main issue (as always, really). Has anyone > noticed any changes compared to DBISAM? How do repairs work? Faster? > Never any issues? Always solved the problem? (I just got a DBISAM > 3-using customer who had a power failure -- damage to one table was > irreparable) ElevateDB is really rock solid ![]() The very rare issues I had were very easy to fix with the REPAIR TABLE statement, and i found it very fast. -- Fernando Dias [Team Elevate] |
Sat, Oct 29 2011 7:14 PM | Permanent Link |
Dominique Willems | Many thanks for your quick reply, Fernando. Most of it is as I expected.
> The very rare issues I had were very easy to fix with the REPAIR > TABLE statement, and i found it very fast. That's one of the things that is a bit of a problem in some of my DBISAM projects. Some very large tables take easily five minutes to verify. An eternity for many users. I don't know if this can be done in a separate thread in ElevateDB (accessing the DB in the main thread while verifying in a background thread)? |
Sat, Oct 29 2011 7:44 PM | Permanent Link |
Fernando Dias ![]() | Dom,
> I don't know if this can be done in > a separate thread in ElevateDB (accessing the DB in the main thread > while verifying in a background thread)? You can use the VERIFY statement while using the tables, but not REPAIR. REPAIR requires the exclusive use of the table being repaired. -- Fernando Dias [Team Elevate] |
Sat, Oct 29 2011 8:04 PM | Permanent Link |
Dominique Willems | Fernando Dias wrote:
> REPAIR requires the exclusive use of the table being > repaired. Yes, that's the problem. Speed is of the essence here. It would be nice if the VERIFY could create a repair strategy in the background, knowing exactly what needs to be done, which records are damaged, etc., speeding up the eventual REPAIR drastically. |
Sat, Oct 29 2011 9:14 PM | Permanent Link |
Fernando Dias ![]() | Dom,
A VERIFYTABLE() function has been in my wish-list for some time ![]() ![]() -- Fernando Dias [Team Elevate] |
Sun, Oct 30 2011 4:25 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Dominique
>1) do you need to deploy any files along with a virgin setup or can >they call be created by the .EXE on first run? To qualify Fernando's a bit. You can create *almost* everything in the EXE on first run. What you can't create from the .exe are any external extensions to the engine. Extensions created in SQL can be created by the .exe but anything created in Delphi has to be distributed as a dll - I've got 5 of them. >2) did you ever notice any speed difference with DBISAM? Sure did. One of my main motivators for the move was full text indexing and that's much faster. Other areas I haven't noticed >3) I won't be needing any client/server stuff; just plain old local DB, >and won't even be using any SQL. Most of the DB will be mapped onto an >Object Persistence Layer and most data will be manipulated right there. >Okay, not really a question here, just inviting any comments wrt >ElevateDB advantages; I'm also not using client/server but as Fernando says you will HAVE to use SQL for some things, and its certainly worth looking at for others. Most of my stuff is done via table handling but SQL is better for some things. >4) robustness will be a main issue (as always, really). Has anyone >noticed any changes compared to DBISAM? How do repairs work? Faster? >Never any issues? Always solved the problem? (I just got a DBISAM >3-using customer who had a power failure -- damage to one table was >irreparable) I'd say a bit more robust than DBISAM. However, in development mode, I have managed to trash a table a time or two. I've also managed to do some strange things when backing up and restoring from Acronis. ElevateDB is different from DBISAM in many areas and its worth trying to spot the differences before they bite you. Have a look through the newsgroups for my name and you'll find a lot of moans from the early days and also a lot of pointers to the differences. Roy Lambert [Team Elevate] |
Sun, Oct 30 2011 8:49 AM | Permanent Link |
Dominique Willems | Roy Lambert wrote:
> What you can't create from the .exe are any > external extensions to the engine. External extensions to the engine? Do you have an example? > I'm also not using client/server but as Fernando says you will HAVE > to use SQL for some things, and its certainly worth looking at for > others. Most of my stuff is done via table handling but SQL is better > for some things. No problem with the occasional SQL. Just always found it counter-intuitive to use interpreted text in a compiled application. ![]() Although today it has absolutely zero impact on execution, unless you put it in a gigantic loop, of course. ![]() > you'll find a lot of moans from the early > days and also a lot of pointers to the differences. Looking forward to browse through your moans. ![]() |
Mon, Oct 31 2011 3:29 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Dominique
>Roy Lambert wrote: >> What you can't create from the .exe are any >> external extensions to the engine. > >External extensions to the engine? Do you have an example? Look in the extensions newsgroup >> I'm also not using client/server but as Fernando says you will HAVE >> to use SQL for some things, and its certainly worth looking at for >> others. Most of my stuff is done via table handling but SQL is better >> for some things. > >No problem with the occasional SQL. Just always found it >counter-intuitive to use interpreted text in a compiled application. ![]() >Although today it has absolutely zero impact on execution, unless you >put it in a gigantic loop, of course. ![]() The big advantage is that for bulk operations on the tables its easier for it to not interact with the user and hence is a lot faster. You can get pretty near the speed using tables that aren't linked to visual controls, datasources or anything. Its also a lot less coding to say UPDATE table SET column = CURRENT_TIMESTAMP WHERE column = test than the equivalent Delphi. >> you'll find a lot of moans from the early >> days and also a lot of pointers to the differences. > >Looking forward to browse through your moans. ![]() <giggle> Roy Lambert [Team Elevate] |
Mon, Oct 31 2011 8:25 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | Dominique,
<< That's one of the things that is a bit of a problem in some of my DBISAM projects. Some very large tables take easily five minutes to verify. An eternity for many users. I don't know if this can be done in a separate thread in ElevateDB (accessing the DB in the main thread while verifying in a background thread)? >> I just did a structural verify on a 2+ million row table with 13 indexes in EDB, and it completed in about 3 minutes. Of course, the big problem with larger tables is that the operations become disk-bound in some cases. In such cases, it is worth trying to bump up the default table buffer sizes using ALTER TABLE, which may help alleviate some of the load. The settings that you want are these: [MAX ROW BUFFER SIZE <MaxRowBufferSize>] [MAX INDEX BUFFER SIZE <MaxIndexBufferSize>] [MAX BLOB BUFFER SIZE <MaxBLOBBufferSize>] [MAX PUBLISH BUFFER SIZE <MaxPublishBufferSize>] http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=ALTER_TABLE You can also very easily change these parameters via the EDB Manager Alter Table task link after clicking on the desired table. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |