Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General Discussion » View Thread |
Messages 21 to 30 of 30 total |
Can I propose DBISAM 5? |
Sat, Feb 2 2008 6:02 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
>and I'm well aware of them. However, every single one is due to an issue >with *DBISAM*, not EDB. "Issues" can become well loved >Also, you're showing a table-specific version of the generic >script that I worked up for you that will do an INTO for *any* query with a >few simple parameters. IOW, 5-10 extra lines of SQL code for *every* INTO >in your application: What you supplied started me thinking for a number of areas, but your assumption is slightly wrong. It would work for every INTO that shares that pattern. I could extend it with a simple test to handle a pattern without an order by, and with a fair bit of work to handle one with multiple indices wanted which is currently processed with a DBISAM style script but I wanted to compare apples with apples. At the end of the day SQL/PSM is just another programming language (took a bit of time for that to penetrate my rusty old brain) so I can write functions/procedures to do a lot, and will probably end up doing so (I need to think what I want in the catalog and what I want in the app) >This could be expanded to automatically create temporary tables instead, or >to create them in a special in-memory database, etc. The DBISAM one already does well the memory bit anyway it doesn't have temporary tables unless you roll your own. ><< Don't know how I'd do this. >> > >Call the TEDBQuery, TEDBStoredProc, or TEDBScript Refresh method. That's >it. The way it was written I thought there was some magic way of them refreshing themselves when the source table was altered. >The SQL scripts in DBISAM can't possibly do something as complicated as >cross-tab result set generation. EDB can do it with a script and a few >simple parameters with no problem. From the original post <<without having to write a single line of SQL code.>> which was the bit that really interested me. I'm all for things that do the work for me ><< Arrgh - I'm sure I'll get used to them >> > >Well, if you even attempt to argue that the way DBISAM handles it is better, >I'll know you're lying. DBISAM's implementation of date/time >calculations and units of measure is sorely lacking. You have days and >milliseconds, and that is it. To get something as simple as the difference >between two times in minutes requires all sorts of embedded division >operations. Its certainly far richer, and eventually I'll figure out where to stick the various bits to get the right effect. At the moment its trail and error..error..error.. ><< OnFilterRecord - wash your moth out >> > >You'd be surprised how many people use it, and the expectations are that it >works like EDB, not DBISAM. Always surprises me. I used them a couple of times when using Paradox but when I switched to V2 filtering was so much better I dumped them. >With EDB, you're guaranteed to get >a progress message every X number of milliseconds. Hadn't realised that consequence. Nice one. Roy Lambert |
Sat, Feb 2 2008 6:17 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Lance
>The thing with the Null's is that several, such as MySQL and Oracle, a Null >is not the same thing as an empty string. I think this is actually default >database behaviour. Its the standard. >If I add a column and want to then go back through the old records that were >made prior to the column Isn't that all of them? >I can then search for NULL and deal with them as >necessary. Granted, I could just as easily search for an empty string... >however... It may be a field that when empty, would be a correct value. I'd prefer to deal with them when I add the column, but its a matter of taste. It also assumes that the column never gets data added to the old records. When Tim first told us about nulls vs empty strings I asked for real examples. I got several hypothetical one's and one real one. To me the real one was, unfortunately, not a good one. From memory it was some sort of questionnaire and they allowed a blank entry to indicate answered but no data. My basic problem is that I don't know any standard controls that show the difference between empty string and null. I like what Tim's down to the grid in EDBManager, but if you follow the famous example I wonder how many letters would get addressed to Tim NULL Young Roy Lambert |
Sat, Feb 2 2008 6:22 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | <<DBISAM is about 10 years>>
Is it really that long? Roy Lambert |
Sat, Feb 2 2008 7:33 PM | Permanent Link |
"Rita" | Yep I got my 1st Dbisam coz of the millenium scare.
All sorta things was meant to happen and I didn't trust the DBF format, plus Tim was just a spotty face kid and I thought he will outlive me. SQL in a BDE replacement sheeeeezzzzzzzz where was Tim and Eryk when people messed with TP7 and Topaz or Halcyon, at school I guess "Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message news:CC5E5BC7-25C4-4F65-A650-F631055005F6@news.elevatesoft.com... > <<DBISAM is about 10 years>> > > Is it really that long? > > Roy Lambert |
Mon, Feb 4 2008 4:37 AM | Permanent Link |
FWIW, I now agree. DBISAM should stay as it is. Which sort of satisfies
Tim's requirement of knowing which versions to support doesn't it. Looks like D2007 will be the last version supported, with D2008 needing ElevateDB to continue. /Matthew Jones/ | |
Mon, Feb 4 2008 9:30 AM | Permanent Link |
Dan Rootham | Matthew,
<< FWIW, I now agree. DBISAM should stay as it is. >> Me too. I was very reluctant to move from tried and trusted DBISAM to "difficult" EDB, but it became clear that Unicode would not be available in DBISAM. So I started converting our applications to EDB. Painful, but necessary... And worth it in the end. Regards, Dan |
Mon, Feb 4 2008 3:26 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< Is it really that long? >> Yep, 10 years this August. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Feb 4 2008 3:32 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< "Issues" can become well loved >> Yes, I suppose they can. << At the end of the day SQL/PSM is just another programming language (took a bit of time for that to penetrate my rusty old brain) so I can write functions/procedures to do a lot, and will probably end up doing so (I need to think what I want in the catalog and what I want in the app) >> The beauty of it becomes even more clear once you write a bunch of native Delphi functions in an external module and access them from within an SQL/PSM script or procedure. You're not just limited to the built-in functions. << The way it was written I thought there was some magic way of them refreshing themselves when the source table was altered. >> No, nothing that "magical". << Its certainly far richer, and eventually I'll figure out where to stick the various bits to get the right effect. At the moment its trail and error..error..error.. >> Sure, it takes a while to remember the syntax. I still have to look-up a lot of the SQL syntax via the manual. << Always surprises me. I used them a couple of times when using Paradox but when I switched to V2 filtering was so much better I dumped them. >> It's most useful when you simply want to filter on the client-side based upon application variables, etc. that cannot be expressed in a normal filter. Because it is incremental with EDB, you usually don't have to pass a huge number of rows over to the client to do the filtering - it stops when it has enough rows to use for the data-aware controls. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Feb 5 2008 3:27 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
>The beauty of it becomes even more clear once you write a bunch of native >Delphi functions in an external module and access them from within an >SQL/PSM script or procedure. You're not just limited to the built-in >functions. My brain hadn't got that far yet .... interesting. >Sure, it takes a while to remember the syntax. I still have to look-up a >lot of the SQL syntax via the manual. What hope is there for me then? Roy Lambert |
Tue, Feb 5 2008 7:23 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< What hope is there for me then? >> Well, considering there is a manual with the answers, plenty. -- Tim Young Elevate Software www.elevatesoft.com |
« Previous Page | Page 3 of 3 | |
Jump to Page: 1 2 3 |
This web page was last updated on Wednesday, April 24, 2024 at 11:07 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |