Icon View Thread

The following is the text of the current message along with any replies.
Messages 21 to 30 of 30 total
Thread Can I propose DBISAM 5?
Sat, Feb 2 2008 6:02 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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 Smiley

>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 Smileywell 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 Smiley

><< Arrgh - I'm sure I'll get used to them Smiley>>
>
>Well, if you even attempt to argue that the way DBISAM handles it is better,
>I'll know you're lying. SmileyDBISAM'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.. Smiley


><< OnFilterRecord - wash your moth out Smiley>>
>
>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 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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? Smiley

>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 Smiley

Roy Lambert
Sat, Feb 2 2008 6:22 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

<<DBISAM is about 10 years>>

Is it really that long?

Roy Lambert
Sat, Feb 2 2008 7:33 PMPermanent 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. Wink
SQL in a BDE replacement sheeeeezzzzzzzz where
was Tim and Eryk when people messed with TP7
and Topaz or Halcyon, at school I guess Wink

"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 AMPermanent 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 AMPermanent 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.Smiley

Regards,
Dan
Mon, Feb 4 2008 3:26 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< "Issues" can become well loved Smiley>>

Yes, I suppose they can. Smiley

<< 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". Smiley

<< 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.. Smiley>>

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 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< What hope is there for me then? >>

Well, considering there is a manual with the answers, plenty. Smiley

--
Tim Young
Elevate Software
www.elevatesoft.com

Previous PagePage 3 of 3
Jump to Page:  1 2 3
Image