Luke Webber ha scritto:
Luke,
which version of D3 are You running?

Based on my tests:
D3/Linux 7.2.0 - 6 digits
D3/Nt 7.3.6 - 7 digits


On D3/Nt 7.3.6 I conducted the following test:

CREATE-FILE TEST 1 1999

CREATE-INDEX TESTFILE A1

Polulated the file with 4,000,000 items (item-id 1..4000000) with
a single byte in attribute 1 in the range A..Z to have, more or
less, 130,000 items with the same repeated key.

Executed 500,000 readu/write and/or readu/delete/write operations
randomly changing attribute 1 (always in the range A..Z)

Executed select and sselect with and without the use of indexies
and then compared the results: no differences.

Maybe I'm very lucky. ;-)

I know this test is a proof of nothing but, if the limit is for the
whole file, I'll expect some kind of corruption.


Stefano

And of course, compared to Assembler, the UP is not a stone ax(e)? No wonder
RD is so behind the times!

As one who had dealt with the Pick assembler for 15+ years, I must say it's
boring to hear it being blamed for not fixing anything. The fact of the
matter is that any competent programmer can learn the old innards given a
little time. And the entire system can, indeed, be reprogrammed in whatever
language you choose. Vide Universe, Unidata, Univision et al.(aside- maybe
RD needs to change their name again?) So let's not confuse possibility with
inability and inaction, as RD is solidly in the latter camp.

Chandru

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

I've been reading this thread for a while and I guess I'll put on my flame
suit and put in my 2 cents worth.

But let me preface this with two things...

1. I don't like the poor documentation regarding limitations within RD's
Pick system.
2. Blowing off steam in a public form is not conducive to spreading the
message of how great a MV system is.

People need to learn the limitations of any tool they use, and then don't
try to push the limits of the tool. Pushing a tool past the limits of what
it can handle give 'unexpected results'!

As for Luke's problem, better documentation may have prevented him from
blowing off steam...

I learned very early in the release of AP and D3 the limits of the indexing
function and did my best to setup my indexes to best exploit this feature.
I been able to take the selection process of access statement from 15 to 20
minutes down to seconds. I mostly use indexes just in a pre-selection
process to gather a list of keys that offer the possibility of holding the
information I need. Then I use a second access (AQL) statement to further
refine the selection. This process works well.

When I need to scan through indexes spanning dates, I usually resort to
using a BASIC program and the root and key statements to cycle through the
dates to gather the required keys. This is done because AQL requires an
equal sign (=) in order to use the Pick indexes.

Some people have put forth a good approach for creating an index where the
index key ends in YYYY or YYYYMMDD, and thereby allow the selection of a
years, months, etc worth of keys in short order and allows a second AQL
statement to further refine the select. This is a very smart idea.

I've found in my work that many people are overlooking the possibility of
using D3's ability to see the spooler entries as a regular item. The
spooler an easy and very fast way of building a huge string. I've found
that using the spooler in this fashion can speed up the processing of
building reports for export by a huge amount.

Is anybody using the ASSIGNFQ function? There is an example in the manual
of spooler reports directly to a operating system file, and it works well
under Linux.

Ya gotta know the limits of the tools you work with!!!

Come on folks! Let's stop throwing dirt! It just makes us look like we
have a dirty system. And who wants to buy a dirty system. People keep
complaining about the marketing effort of the system makers and the VAR's.
But there seems to be a whole lot of anti-marketing crap being spread
through the newsgroup.

Whether or not possible clients ever look at CDP to see if we have a good
back-end, you should be writing your posting like if the do. You will never
know if you've blown off a possible client and income by the rhetoric that
gets posted here.

I'm sounding too much like Tony!

Regards,

Dale

"Luke Webber" <luke (AT) webber (DOT) com.au> wrote

stefano wrote:

Whups! I said six digits, but it was actually seven. Still not enough,
though, because the file had 28 million records in it, and that's eight
digits. Weird that they should extend the size by one lousy digit. Why
not just remove the limit entirely?

The words "unpredictable results" are kind of chilling, aren't they?
Could take in any result from "working perfectly" to "Hey, where has my
data gone?"

Luke

"Dale Benedict" wrote:
LOL, maybe that's why until I got down to this line I was thinking to
myself "way to go Dale" "yeah, you tell um bud" ... Gee, only one
dinner with this choir boy and you're singin the gospel, maybe I've
been approaching this forum thing all wrong.

Seriously, all good advice, and something to remember right before we
click that Send button.

BTW, I'm not sure if anyone noticed but RD did add some enhancements
around 7.4.x to allow indexed date range selection and some other
goodies. I haven't used the mods, can't comment.

T

Tony:

I'm not sure this works, as I still cannot access indexes except with an
equality. :-(

But then I don't index dates. :-)

Bill

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote ...

[snipped]

You know, the company I'm with doesn't even sell applications, so I have
little vested interest at this time to ensure that Pick databases get a
bigger foothold in the market place. Who knows maybe in the future I'll be
trying to sell software or be with a company who does sell software built
with a Pick database as the back end.

All that has been said in this thread disappoints me. I've worked with
other databases on and off (mostly off) over my career and haven't found any
other database/application programming system that can create a highly
effective and flexible system. I still hear chuckles from around a 'water
cooler' where a company creating their own software to replace the software
that was built in Pick requesting a change. The Pick system was altered in
less than a week, and the flashy software that was being built for them was
going to take an extra 6 month to accommodate the changes.

I learned within weeks of AP/DOS first showing up much of the limitations of
the indexing. On just has to learn the limits of the tool, step back from
the problem to see the big picture and then use the tools at hand to get the
job done as best as possible. The final process may not be the ideal
solution as seen from the programmer's standpoint, but as long as the
solution works and is maintainable, that all that really matters.

Regards,

Dale

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote