Maximum key size

[Database Administrator]

Does anyone know what the maximum size of a key can be on D3? I can
find it in the online version of the docs. I seem to remember a long
time ago something about 50 but that could have been the maximum size
of a file name or even a limit that has since changed from eons ago.

I have found some keys to be 66 characters in length and was wondering
if I could potentially run into some even longer. It seems that
someone made the key to one of the files here be the book title.

Thanks

[Database Administrator]

eppick77 wrote:
> Does anyone know what the maximum size of a key can be on D3? I can
> find it in the online version of the docs. I seem to remember a long
> time ago something about 50 but that could have been the maximum size
> of a file name or even a limit that has since changed from eons ago.
>
> I have found some keys to be 66 characters in length and was wondering
> if I could potentially run into some even longer. It seems that
> someone made the key to one of the files here be the book title.
>
> Thanks

A BASIC like this might tell you:

EXECUTE 'CREATE-FILE TESTING 1 1'
OPEN 'TESTING' TO TEST.FV ELSE STOP 201,'TESTING'
DONE = 0
FOR I = 1 TO 500 UNTIL DONE
ID = STR('X',I)
WRITE I ON TEST.FV,ID
READ TEST.REC FROM TEST.FV,ID ELSE
CRT 'FAILS AT ':I
DONE = 1
END
NEXT I

A public flogging of the "someone" who chose the
title to be the Item-ID might help, too. =`;^P

--
frosty

[Database Administrator]

On Nov 12, 3:32*pm, "frosty" wrote:
> eppick77 wrote:
> > Does anyone know what the maximum size of a key can be on D3? *I can
> > find it in the online version of the docs. *I seem to remember a long
> > time ago something about 50 but that could have been the maximum size
> > of a file name or even a limit that has since changed from eons ago.
>
> > I have found some keys to be 66 characters in length and was wondering
> > if I could potentially run into some even longer. *It seems that
> > someone made the key to one of the files here be the book title.
>
> > Thanks
>
> A BASIC *like this might tell you:
>
> EXECUTE 'CREATE-FILE TESTING 1 1'
> OPEN 'TESTING' TO TEST.FV ELSE STOP 201,'TESTING'
> DONE = 0
> FOR I = 1 TO 500 UNTIL DONE
> * ID = STR('X',I)
> * WRITE I ON TEST.FV,ID
> * READ TEST.REC FROM TEST.FV,ID ELSE
> * * CRT 'FAILS AT ':I
> * * DONE = 1
> * END
> NEXT I
>
> A public flogging of the "someone" who chose the
> title to be the Item-ID might help, too. *=`;^P
>
> --
> frosty

Thanks. I tried that program and got some very interesting results.
I thought that I would share them with you.

The program NEVER hit the else statement and printed that it failed.

It turns out that D3 apparently truncates the key and just keeps
writing so that it always was able to read the record. The maximum
record size appears to be 101.

As to the public flogging of the person who put the book title as the
key - when I find them and do the flogging, I will be selling tickets!


Eugene

[Database Administrator]

> As to the public flogging of the person who put the book title as the
> key - when I find them and do the flogging, I will be selling tickets!
>

Oh my. Systems like that are so much fun.

--
Kevin Powick

[Database Administrator]

Kevin Powick wrote:

>> As to the public flogging of the person who put the book title as the
>> key - when I find them and do the flogging, I will be selling tickets!
>>
>
>Oh my. Systems like that are so much fun.

And usually include CustomerMaster files that have attributes like
this:

101 OpenInvoices]v]v]v]v]v]v]...
102 ClosedInvoices]v]v]v]v]v]...
103 OpenOrders]v]v]v]v]v]v]v]...
104 ClosedOrders]v]v]v]v]v]v]...

Or in the COMPANY file:
MASTER.KEYS
01 NextOrder#
02 NextCust#
03 NextInvoice#
....
Go ahead, make my day and lock that record every time you need a new
key.

In almost every MV developer's life there is a moment when they
realize that there are things that can be done, but which certainly
should not.

T

[Database Administrator]

HI Tony
I am very interested in techniques for controlling things such as invoice
numbers etc - I did start my working life as an auditor :-)
Obviously one can get the system to issue a next number however that would
still have to be atomic and therefore I assume that it would have to issue a
lock, so I am intrigued at your lock free suggestion.
Running lists of outstanding items I do through BTrees as the thought of
massively expanding master files still gives me the horrors although the 32k
limit days are long gone. I remember DataMail crashing on that one in South
Melbourne circa 1978. However I have seen worse in the last 10 years. A
banking package that added every transaction as a new multi-valued attribute
to the customer account, and another package that had the entire 3000 item
stock price list in an item imaginatively stored in a file called PRICES
containing one item called PRICE.
Peter McMurray
"Tony Gravagno" wrote in
message news:b91nh45685livdu1o56m60eo3uk46e1l5h@4ax.com...
> Kevin Powick wrote:
>
>>> As to the public flogging of the person who put the book title as the
>>> key - when I find them and do the flogging, I will be selling tickets!
>>>
>>
>>Oh my. Systems like that are so much fun.
>
> And usually include CustomerMaster files that have attributes like
> this:
>
> 101 OpenInvoices]v]v]v]v]v]v]...
> 102 ClosedInvoices]v]v]v]v]v]...
> 103 OpenOrders]v]v]v]v]v]v]v]...
> 104 ClosedOrders]v]v]v]v]v]v]...
>
> Or in the COMPANY file:
> MASTER.KEYS
> 01 NextOrder#
> 02 NextCust#
> 03 NextInvoice#
> ...
> Go ahead, make my day and lock that record every time you need a new
> key.
>
> In almost every MV developer's life there is a moment when they
> realize that there are things that can be done, but which certainly
> should not.
>
> T

[Database Administrator]

Hi Peter,

I don't think that Tony is suggesting NO locking - more that multiple
"next item-id" keys into a single item is bound to lead to clashes as
different processes try to access that single item. i.e. each "next
item-id" should have its own item.

Cheers,

Brian

Peter McMurray wrote:
> HI Tony
> I am very interested in techniques for controlling things such as
> invoice numbers etc - I did start my working life as an auditor :-)
> Obviously one can get the system to issue a next number however that
> would still have to be atomic and therefore I assume that it would have
> to issue a lock, so I am intrigued at your lock free suggestion.
> Running lists of outstanding items I do through BTrees as the thought of
> massively expanding master files still gives me the horrors although the
> 32k limit days are long gone. I remember DataMail crashing on that one
> in South Melbourne circa 1978. However I have seen worse in the last 10
> years. A banking package that added every transaction as a new
> multi-valued attribute to the customer account, and another package that
> had the entire 3000 item stock price list in an item imaginatively
> stored in a file called PRICES containing one item called PRICE.
> Peter McMurray
> "Tony Gravagno" wrote in
> message news:b91nh45685livdu1o56m60eo3uk46e1l5h@4ax.com...
>> Kevin Powick wrote:
>>
>>>> As to the public flogging of the person who put the book title as the
>>>> key - when I find them and do the flogging, I will be selling tickets!
>>>>
>>>
>>> Oh my. Systems like that are so much fun.
>>
>> And usually include CustomerMaster files that have attributes like
>> this:
>>
>> 101 OpenInvoices]v]v]v]v]v]v]...
>> 102 ClosedInvoices]v]v]v]v]v]...
>> 103 OpenOrders]v]v]v]v]v]v]v]...
>> 104 ClosedOrders]v]v]v]v]v]v]...
>>
>> Or in the COMPANY file:
>> MASTER.KEYS
>> 01 NextOrder#
>> 02 NextCust#
>> 03 NextInvoice#
>> ...
>> Go ahead, make my day and lock that record every time you need a new
>> key.
>>
>> In almost every MV developer's life there is a moment when they
>> realize that there are things that can be done, but which certainly
>> should not.
>>
>> T
>

[Database Administrator]

Yup - Brian wins the prize.

Brian Speirs wrote:

>Hi Peter,
>I don't think that Tony is suggesting NO locking - more that multiple
>"next item-id" keys into a single item is bound to lead to clashes as
>different processes try to access that single item. i.e. each "next
>item-id" should have its own item.

>Peter McMurray wrote:
>> I am very interested in techniques for controlling things such as
>> invoice numbers etc