Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General Discussion » View Thread |
Messages 31 to 40 of 43 total |
Questions on Catalogs |
Fri, Oct 31 2008 3:00 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
>You're part of Team Elevate, you can have the source code now if you want. >I think you'll see that it is a little more complicated than you might >think. We need rules on this newgroup to prevent obscenities like that offer. Roy Lambert |
Fri, Oct 31 2008 12:36 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< We need rules on this newgroup to prevent obscenities like that offer. >> Seriously, though, if you want the source code just email Sam and she'll set you up. -- Tim Young Elevate Software www.elevatesoft.com |
Sat, Nov 1 2008 7:32 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
If I ever manage to make enough money to be able to take a couple of months of so I have a chance of understanding the code I might do that. Whilst I know you write good code its not in my format (I hate the hanging Borland style) and there's a lot of it. This is why in my initial post I said after a lottery win - I'd be a man of leisure then and have the time to do it justice. Roy Lambert |
Tue, Nov 4 2008 1:48 AM | Permanent Link |
"David Cornelius" | > Whilst I know you write good code its not in my format (I hate
> the hanging Borland style) and there's a lot of it. http://jedicodeformat.sourceforge.net/ -- David Cornelius CorneliusConcepts.com |
Tue, Nov 4 2008 2:24 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | David
Thanks for the link. I'm currently using DelForEx in GExperts (I've used DelForEx for ages). One thing it won't do, quite rightly, is remove line breaks if you add them manually (surplus blank lines between procedures are zapped). Hence if someone has used the Borland style DelForEx will not bring the "then begin" onto the same line. Does the Jedi one? Roy Lambert |
Tue, Nov 4 2008 10:54 AM | Permanent Link |
"David Cornelius" | > Thanks for the link. I'm currently using DelForEx in GExperts (I've
> used DelForEx for ages). One thing it won't do, quite rightly, is > remove line breaks if you add them manually (surplus blank lines > between procedures are zapped). Hence if someone has used the Borland > style DelForEx will not bring the "then begin" onto the same line. > Does the Jedi one? I believe it does, but it's been a while since I used it. I once used DelForEx as well; the Jedi one is incredibly powerful, compared. -- David Cornelius CorneliusConcepts.com |
Mon, Nov 10 2008 6:13 AM | Permanent Link |
Leslie | Tim,
If I've got right, this discussion is about incremental metadata replication. This is what I am planning to do: 1. Suppose the program used to to design and manage the databases could log the SQL's generated for every metadata change. 2. When the changes needs to be replicated they are deployed as a script with a version number, which can be treated as the version of the database. 3. The update script is executed before the DB is opened. 4. When the database is openned by an application, the app checks the dbversion it requires against the version in the db. This can be easily done form code, but it would be useful to have a TEDBDataBase.OpenRequiredDBVersion(<dbversion>; ExactmatchRequired: boolean) method. 5. When more then one apps are using the same db, somehow needs to be checked if they are all compatible with the new version of the db before the changes are applied. For that I would have every version of the applications and the DB version they require registered in a separate db in a separate catalog . The script which automates deploying all changes (exe, metadata ...) could store all updates (scripts, exe ... ) there. 6 After a DB restore all changes can be autamitcally applied again. Of course I will have to write my own DBManager, unless you decide (and find the time) to include SQL logging into EDBManager. --- About the singlefile db question: you could try SingleFileSytem, SolidFileSystem or something similar. This approach would require probably only very small changes. Though it may effect performance much more. Or not at all. To tell the truth when I first read about EDB I have discarded it because of not having a single file database, and only your willingness of porting EDB for WinCE made me take a closer look at EDB again. (: Which I am glad I did Your explanation is perfectly clear why it is so, but I am sure that, the first reaction of many experienced programmers is similar to this: "This is the way it was in the old days, no serious new SQL engines are like this any more." If you want to market EDB as a viable alternative of the widely known SQL engines, I think this is a kind of must have. Regards, Leslie |
Mon, Nov 10 2008 1:01 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Leslie,
<< Of course I will have to write my own DBManager, unless you decide (and find the time) to include SQL logging into EDBManager. >> The EDB Manager already has SQL logging (it's called SQL History), and the default is 30 statements, but you can increase the number of statements logged to anything that you want. I'll see about possibly segmenting the logging by database name, which would help immensely with what you're proposing. << About the singlefile db question: you could try SingleFileSytem, SolidFileSystem or something similar. This approach would require probably only very small changes. Though it may effect performance much more. Or not at all. To tell the truth when I first read about EDB I have discarded it because of not having a single file database, and only your willingness of porting EDB for WinCE made me take a closer look at EDB again. (: Which I am glad I did Your explanation is perfectly clear why it is so, but I am sure that, the first reaction of many experienced programmers is similar to this: "This is the way it was in the old days, no serious new SQL engines are like this any more." If you want to market EDB as a viable alternative of the widely known SQL engines, I think this is a kind of must have. >> I really don't want to get into this discussion again. If you do a search on these newsgroups: http://www.elevatesoft.com/newsgrp?action=search&group=0 you will find thread after thread about why we don't use a single file database. And, honestly, "everyone does it" is not a valid reason to do anything. There are technical reasons for, and against, using a single-file database format, and just doing it for the heck of it is both silly and can kill the performance of a file-sharing, multi-user database (which both EDB and DBISAM provide) very quickly. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Nov 10 2008 2:23 PM | Permanent Link |
Leslie | Tim
<<The EDB Manager already has SQL logging (it's called SQL History), and the default is 30 statements, but you can increase the number of statements logged to anything that you want. I'll see about possibly segmenting the logging by database name, which would help immensely with what you're proposing.>> Would be great. <<And, honestly, "everyone does it" is not a valid reason to do anything. There are technical reasons for, and against, using a single-file database format, and just doing it for the heck of it is both silly and can kill the performance of a file-sharing, multi-user database (which both EDB and DBISAM provide) very quickly.>> I think you did not get my point. You are concentrating on the technical issues, I am not arguing with you there. What I have tried to bring to your attention is the marketing/business aspects of it. Not having a single file database puts EDB into the wrong group of engines in the minds of many programmers. EDB clearly has the potential to be more then a modern DBISAM replacement, it may become contender for widely used SQL engines. (: v3.x or v4.x It is really up to your business model, what kind of costumers you would like to attract. Also those people who are requesting single file database probably do not need the features which are against having it. You could make it as an option (as firebird does): "If you do not need these special features .... " I made peace with the way it is, and there are many features which are much more important for me, but I still think testing how a 3rdparty Single File library would effect performance is worth a try sometimes. And I still think that it is an important factor in how EDB is viewed. Which probably will effect your sales at some point. <<I really don't want to get into this discussion again.>> Do not worry, me neither. So please do not spend your time on answering me. (I really mean it!) Regards, Leslie |
Mon, Nov 10 2008 2:52 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Leslie,
<< I think you did not get my point. You are concentrating on the technical issues, >> Of course I am. A single-file database format would simply not work for EDB given its current architecture. That's a fact, and there's no getting around it. You cannot do the type of multi-user locking that we do with a single-file database format, and still maintain any semblance of performance. << I am not arguing with you there. What I have tried to bring to your attention is the marketing/business aspects of it. Not having a single file database puts EDB into the wrong group of engines in the minds of many programmers. EDB clearly has the potential to be more then a modern DBISAM replacement, it may become contender for widely used SQL engines. (: v3.x or v4.x It is really up to your business model, what kind of costumers you would like to attract. >> I'm sorry, but I don't think that the file format is the #1 issue that developers care about when looking at a product. Anyone can do a single-file database format, and it's not a big deal *by itself*. It's all of the other issues like performance and locking that get in the way. << Also those people who are requesting single file database probably do not need the features which are against having it. You could make it as an option (as firebird does): "If you do not need these special features .... " I made peace with the way it is, and there are many features which are much more important for me, but I still think testing how a 3rdparty Single File library would effect performance is worth a try sometimes. And I still think that it is an important factor in how EDB is viewed. Which probably will effect your sales at some point. >> First of all, just adding a single-file library underneath the engine does absolutely nothing for EDB except remove the multi-user, file-sharing capabilities and permitting EDB to only be used as a single-user or server database engines, regardless of any marketing implications. Secondly, we have already stated numerous times publicly that we are working on an enterprise version of the ElevateDB Server that will indeed have a single-file database format and will *only* be used as a server engine. However, I try not to mention this in the context of a discussion of EDB because it muddies the waters with respect to any discussion of the *current* EDB engine. Finally, as far as marketing is concerned. We do not, nor have we ever, been overly concerned with marketing because we believe that trying to drive product development in this way is a disaster. It results in companies spending huge amounts of time on features that have very little payoff. This is obvious by the way these discussions are structured. There's always the dire warnings about "how people view the product" and "whether people will take it seriously" with no regard to actual facts to back up such statements. In these cases, and I include you in this case, we are essentially dealing with people projecting their own personal desires on to a group of people that don't actually exist. And I don't mean that as an insult. It is a natural thing to do, and we all do it. However, it is our job to look at such statements with a rational eye and realize what percentage is truth and what percentage is personal enhancement request. Our product development is driven by prioritizing the feature requests by potential and existing customers, and is backed up by *actual feature requests* that we can keep track of and use to gauge the amount of desire for a particular feature. And, as always, we balance these requests against what is both technically feasible, and whether we will actually deliver on the feature. As already stated, it really doesn't do much good to add a feature that will result in lesser performance and will exclude a segment of our already existing customer base. -- Tim Young Elevate Software www.elevatesoft.com |
« Previous Page | Page 4 of 5 | Next Page » |
Jump to Page: 1 2 3 4 5 |
This web page was last updated on Wednesday, April 17, 2024 at 08:53 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |