Re: [U2] Data in Dict
That only works if the your and the host are both on the same side of the
router,
otherwise, you always get the router's MAC address. If your able to get the mac
address, you could also use the packet id for uniqueness, but that would be
unique for each packet, even from the same host.
George
-Original Message-
From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-
boun...@listserver.u2ug.org] On Behalf Of Steve Romanow
Sent: Tuesday, January 25, 2011 8:24 PM
To: U2 Users List
Subject: Re: [U2] Data in Dict
In some cases I am becoming a fan of UUIDs for db table keys. A UUID
type one uses the mac address of the host along with the current time
as salt so you don't have to worry about key collisions between
accounts (I.e. TEST and PROD). Generating the next key is fast because
there is no readu, update, write. They should hash pretty well since
they are long and random.
On 1/25/11, Bill Haskett wphask...@advantos.net wrote:
Jeff:
I have a single file named (CTRLNOS) with the item ID equal to the
file
name using the sequence#. Field#1 is the last seq# used while field#
2
is the maximum seq# allowed before the seq# is reset to 0. Each item
has documentation in it to describe what it's for and any unusual
pieces
of data allowed (e.g. maximum length of data allowed in a text box).
The get-next-sequence code looks like:
READ{U} SEQREC FROM SEQFILE, FILENAME ELSE
SEQREC = 0:@AM:9:@AM:@AM:@AM
SEQREC := ** Item created on :TIMEDATE():.
END
SEQ = SEQREC1 + 0
MAX.SEQ = SEQREC2 + 0
OSW = 0
LOOP
SEQ += 1
IF SEQ MAX.SEQ THEN
IF NOT(OSW) THEN OSW = 1 ; SEQ = 1
END
READV{U} DoesExist FROM FILENAME.FV, SEQ, 0 ELSE DoesExist = 0
UNTIL NOT(DoesExist) DO REPEAT
If a file goes bad then I know which item to fiddle with. Just a
thought.
Bill
-
---
Jeff Schasny said the following on 1/25/2011 8:37 AM:
My preference is to have a data file specifically for next key
records
with the item id being the filename and field 1 being the next
available key. As far as restoring it should it become corrupted a
fairly simple Uvbasic program which is fed a list of filenames,
selects each file BY.DSND @ID,
readnext,
add 1 to the first key,
write that as the next key for the file,
next filename
should be able to restore your next key file in a couple minutes if
not less.
George Gallen wrote:
The one down side I can think of to not keeping 'next' values in
the
DICT and in a separate file, is if you have to restore the file,
you
will also have to restore the NEXT-FILE as well. It's not one neat
package.
But I have to admit, when I was setting up a MySQL structure and
needed to implement a 'next' value, I went with a separate file and
each row had two values, key and value, where the key was the
filename
and the value being the next value, and used this one file for all
my
'next' placeholders, instead of writing it to the DICT, I used the
filename as the key.
Although, keeping all your nexts in one basket could be a problem
if
that file ever was corrupted, it would be difficult to reset them
all to the correct values. Other than that, seems a bit of overhead
to have a separate next file for each file you want to keep one
on
to avoid losing all your keys with one file issue.
What other methods are people using to track next ID?
-Original Message-
From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-
boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Monday, January 24, 2011 7:55 PM
To: U2 Users List
Subject: Re: [U2] Data in Dict
Kate:
It seems to me that this is very tidy! :-)
Bill
--
-
-
Kate Stanton said the following on 1/24/2011 1:27 PM:
Hi David,
The reason we use dictionaries for data entry, reports, queries
and
forms is so we can use the same dictionary item for all
activities,
thus using the dictionary as designed with a little more.
So, if part ID is changed at a site to be 6 numbers, then
changing
the
dict item in a file once means the same change applies to all
other
activities.
We think this is very tidy, and the unused portion of
dictionaries
have been used like this for a long, long time (over 30 years to
our
knowledge).
Cheers, Kate
Kate Stanton
Walstan Systems Ltd,
4 Kelmarna Ave, Herne Bay, Auckland 1011, New Zealand
Phone: +64 9 360 5310 mobile: + 64 21 400 486 fax: + 64 9 367
0750
Email: k...@walstan.com
On 25 January 2011 03:53, David A.
Greendgr...@dagconsulting.com
wrote:
All this talk about using the Dictionary item to store extra
data
has
prompted this post.
I realize in the past when the limit to the number of Opened
Files
in a
Basic
Re: [U2] Data in Dict
I'm curious what your logic is to generate the Unique ID -- can you share
that without giving away a trade secret??
It's too bad it's not a database function call in UniData/UniVerse - we can
do that in D3/Pick - it's a derivation of system Date/Time with
AlphaSequencing if more than 1 hit in a given clock cycle - but it would
only be unique on the 'machine' since another system could generate the same
ID. So I am interested in the idea of generating a TRULY unique ID.
DW
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow
Sent: Tuesday, January 25, 2011 7:24 PM
To: U2 Users List
Subject: Re: [U2] Data in Dict
In some cases I am becoming a fan of UUIDs for db table keys. A UUID
type one uses the mac address of the host along with the current time
as salt so you don't have to worry about key collisions between
accounts (I.e. TEST and PROD). Generating the next key is fast because
there is no readu, update, write. They should hash pretty well since
they are long and random.
On 1/25/11, Bill Haskett wphask...@advantos.net wrote:
Jeff:
I have a single file named (CTRLNOS) with the item ID equal to the file
name using the sequence#. Field#1 is the last seq# used while field# 2
is the maximum seq# allowed before the seq# is reset to 0. Each item
has documentation in it to describe what it's for and any unusual pieces
of data allowed (e.g. maximum length of data allowed in a text box).
The get-next-sequence code looks like:
READ{U} SEQREC FROM SEQFILE, FILENAME ELSE
SEQREC = 0:@AM:9:@AM:@AM:@AM
SEQREC := ** Item created on :TIMEDATE():.
END
SEQ = SEQREC1 + 0
MAX.SEQ = SEQREC2 + 0
OSW = 0
LOOP
SEQ += 1
IF SEQ MAX.SEQ THEN
IF NOT(OSW) THEN OSW = 1 ; SEQ = 1
END
READV{U} DoesExist FROM FILENAME.FV, SEQ, 0 ELSE DoesExist = 0
UNTIL NOT(DoesExist) DO REPEAT
If a file goes bad then I know which item to fiddle with. Just a thought.
Bill
Jeff Schasny said the following on 1/25/2011 8:37 AM:
My preference is to have a data file specifically for next key records
with the item id being the filename and field 1 being the next
available key. As far as restoring it should it become corrupted a
fairly simple Uvbasic program which is fed a list of filenames,
selects each file BY.DSND @ID,
readnext,
add 1 to the first key,
write that as the next key for the file,
next filename
should be able to restore your next key file in a couple minutes if
not less.
George Gallen wrote:
The one down side I can think of to not keeping 'next' values in the
DICT and in a separate file, is if you have to restore the file, you
will also have to restore the NEXT-FILE as well. It's not one neat
package.
But I have to admit, when I was setting up a MySQL structure and
needed to implement a 'next' value, I went with a separate file and
each row had two values, key and value, where the key was the filename
and the value being the next value, and used this one file for all my
'next' placeholders, instead of writing it to the DICT, I used the
filename as the key.
Although, keeping all your nexts in one basket could be a problem if
that file ever was corrupted, it would be difficult to reset them
all to the correct values. Other than that, seems a bit of overhead
to have a separate next file for each file you want to keep one on
to avoid losing all your keys with one file issue.
What other methods are people using to track next ID?
-Original Message-
From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-
boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Monday, January 24, 2011 7:55 PM
To: U2 Users List
Subject: Re: [U2] Data in Dict
Kate:
It seems to me that this is very tidy! :-)
Bill
---
-
Kate Stanton said the following on 1/24/2011 1:27 PM:
Hi David,
The reason we use dictionaries for data entry, reports, queries and
forms is so we can use the same dictionary item for all activities,
thus using the dictionary as designed with a little more.
So, if part ID is changed at a site to be 6 numbers, then changing
the
dict item in a file once means the same change applies to all other
activities.
We think this is very tidy, and the unused portion of dictionaries
have been used like this for a long, long time (over 30 years to our
knowledge).
Cheers, Kate
Kate Stanton
Walstan Systems Ltd,
4 Kelmarna Ave, Herne Bay, Auckland 1011, New Zealand
Phone: +64 9 360 5310 mobile: + 64 21 400 486 fax: + 64 9 367 0750
Email: k...@walstan.com
On 25 January 2011 03:53, David A. Greendgr...@dagconsulting.com
wrote:
All this talk about using the Dictionary item to store extra data
has
prompted this post.
I realize in the past when the limit to the number
Re: [U2] Data in Dict
In Java, you have the same problem. The UID is only unique for the machine, so
the common trick is to take the IP address of the local machine and use it as a
prefix (should be unique within your network anyways).
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David Wolverton
Sent: Wednesday, January 26, 2011 6:55 AM
To: 'U2 Users List'
Subject: Re: [U2] Data in Dict
I'm curious what your logic is to generate the Unique ID -- can you share that
without giving away a trade secret??
It's too bad it's not a database function call in UniData/UniVerse - we can do
that in D3/Pick - it's a derivation of system Date/Time with AlphaSequencing if
more than 1 hit in a given clock cycle - but it would only be unique on the
'machine' since another system could generate the same ID. So I am interested
in the idea of generating a TRULY unique ID.
DW
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Steve Romanow
Sent: Tuesday, January 25, 2011 7:24 PM
To: U2 Users List
Subject: Re: [U2] Data in Dict
In some cases I am becoming a fan of UUIDs for db table keys. A UUID type one
uses the mac address of the host along with the current time as salt so you
don't have to worry about key collisions between accounts (I.e. TEST and PROD).
Generating the next key is fast because there is no readu, update, write. They
should hash pretty well since they are long and random.
On 1/25/11, Bill Haskett wphask...@advantos.net wrote:
Jeff:
I have a single file named (CTRLNOS) with the item ID equal to the
file name using the sequence#. Field#1 is the last seq# used while
field# 2 is the maximum seq# allowed before the seq# is reset to 0.
Each item has documentation in it to describe what it's for and any
unusual pieces of data allowed (e.g. maximum length of data allowed in a text
box).
The get-next-sequence code looks like:
READ{U} SEQREC FROM SEQFILE, FILENAME ELSE
SEQREC = 0:@AM:9:@AM:@AM:@AM
SEQREC := ** Item created on :TIMEDATE():.
END
SEQ = SEQREC1 + 0
MAX.SEQ = SEQREC2 + 0
OSW = 0
LOOP
SEQ += 1
IF SEQ MAX.SEQ THEN
IF NOT(OSW) THEN OSW = 1 ; SEQ = 1
END
READV{U} DoesExist FROM FILENAME.FV, SEQ, 0 ELSE DoesExist = 0
UNTIL NOT(DoesExist) DO REPEAT
If a file goes bad then I know which item to fiddle with. Just a thought.
Bill
--
-- Jeff Schasny said the following on 1/25/2011 8:37 AM:
My preference is to have a data file specifically for next key
records with the item id being the filename and field 1 being the
next available key. As far as restoring it should it become corrupted
a fairly simple Uvbasic program which is fed a list of filenames,
selects each file BY.DSND @ID, readnext, add 1 to the first key,
write that as the next key for the file, next filename should be able
to restore your next key file in a couple minutes if not less.
George Gallen wrote:
The one down side I can think of to not keeping 'next' values in the
DICT and in a separate file, is if you have to restore the file, you
will also have to restore the NEXT-FILE as well. It's not one neat
package.
But I have to admit, when I was setting up a MySQL structure and
needed to implement a 'next' value, I went with a separate file and
each row had two values, key and value, where the key was the
filename and the value being the next value, and used this one file
for all my 'next' placeholders, instead of writing it to the DICT, I
used the filename as the key.
Although, keeping all your nexts in one basket could be a problem if
that file ever was corrupted, it would be difficult to reset them
all to the correct values. Other than that, seems a bit of overhead
to have a separate next file for each file you want to keep one on
to avoid losing all your keys with one file issue.
What other methods are people using to track next ID?
-Original Message-
From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-
boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Monday, January 24, 2011 7:55 PM
To: U2 Users List
Subject: Re: [U2] Data in Dict
Kate:
It seems to me that this is very tidy! :-)
Bill
---
-
Kate Stanton said the following on 1/24/2011 1:27 PM:
Hi David,
The reason we use dictionaries for data entry, reports, queries
and forms is so we can use the same dictionary item for all
activities, thus using the dictionary as designed with a little more.
So, if part ID is changed at a site to be 6 numbers, then changing
the
dict item in a file once means the same change applies to all
other activities.
We think this is very tidy, and the unused portion of dictionaries
have been used like this for a long, long
[U2] data in dict
Once upon a time, it might have made perfect sense to store in the dict of a file other bits of information to be used by programs. However, since the indroduction of multiple data levels within a file, this would seem to be a non-issue if you just created a fields data portion for a file, and then loaded it up with anything you wanted. This would leave the dictionary clear of anything that might conflict with the OS you are using. Jay ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] data in dict
Hi Jay, What is the 'multiple data levels' you are referring to here - distributed files ? Gerry -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of jay rappaport Sent: January 26, 2011 12:03 PM To: u2-users@listserver.u2ug.org Subject: [U2] data in dict Once upon a time, it might have made perfect sense to store in the dict of a file other bits of information to be used by programs. However, since the indroduction of multiple data levels within a file, this would seem to be a non-issue if you just created a fields data portion for a file, and then loaded it up with anything you wanted. This would leave the dictionary clear of anything that might conflict with the OS you are using. Jay ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Data in Dict
@George No, this all runs server side, so the mac address of the U2 server. Not the client that you are connecting with. It is a moot point because the mac and time are only salt for the random number. @David I am using the uuid library python includes. I have my DEFFUN hosted here. When using it as a function, it is as handy as a db function. https://bitbucket.org/slestak/u2-tools @Robert I am not fully aware of JAVA'a UID, but I have UUID1 and UUID4 available. 2 and 3 could be added, but I didn't have the need for that project. Another use I have started doing is serializing printed outputs. With some recent Bill of Lading testing, every printed BOL has a unique run_id so I can always refer a specific instance of a printout. The pdfs from Optio are saved, so I can recall them if needed and compare to prior runs of the same test. On Wed, Jan 26, 2011 at 9:25 AM, George Gallen ggal...@wyanokegroup.com wrote: That only works if the your and the host are both on the same side of the router, otherwise, you always get the router's MAC address. If your able to get the mac address, you could also use the packet id for uniqueness, but that would be unique for each packet, even from the same host. George ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Data in Dict
Here is an example usage: * *- * Initialize Variables *- * DEFFUN ADD_XML_ELEMENT(a,b,c,d,e,f) DEFFUN UUIDGEN(UUIDTYPE,ARG2) CONO = PARMS(1)1 RUN_ID = UUIDGEN(1,) XML.DIR = @PATH:'/_XML_/' LOGGING.NS = SSCE.GZONE LOC = On Wed, Jan 26, 2011 at 2:19 PM, Steve Romanow slestak...@gmail.com wrote: @George No, this all runs server side, so the mac address of the U2 server. Not the client that you are connecting with. It is a moot point because the mac and time are only salt for the random number. @David I am using the uuid library python includes. I have my DEFFUN hosted here. When using it as a function, it is as handy as a db function. https://bitbucket.org/slestak/u2-tools @Robert I am not fully aware of JAVA'a UID, but I have UUID1 and UUID4 available. 2 and 3 could be added, but I didn't have the need for that project. Another use I have started doing is serializing printed outputs. With some recent Bill of Lading testing, every printed BOL has a unique run_id so I can always refer a specific instance of a printout. The pdfs from Optio are saved, so I can recall them if needed and compare to prior runs of the same test. On Wed, Jan 26, 2011 at 9:25 AM, George Gallen ggal...@wyanokegroup.com wrote: That only works if the your and the host are both on the same side of the router, otherwise, you always get the router's MAC address. If your able to get the mac address, you could also use the packet id for uniqueness, but that would be unique for each packet, even from the same host. George ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Data in Dict
Type4 doesn't use the mac address, so it should be truly random. http://en.wikipedia.org/wiki/Universally_unique_identifier ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Data in Dict
The one down side I can think of to not keeping 'next' values in the DICT and in a separate file, is if you have to restore the file, you will also have to restore the NEXT-FILE as well. It's not one neat package. But I have to admit, when I was setting up a MySQL structure and needed to implement a 'next' value, I went with a separate file and each row had two values, key and value, where the key was the filename and the value being the next value, and used this one file for all my 'next' placeholders, instead of writing it to the DICT, I used the filename as the key. Although, keeping all your nexts in one basket could be a problem if that file ever was corrupted, it would be difficult to reset them all to the correct values. Other than that, seems a bit of overhead to have a separate next file for each file you want to keep one on to avoid losing all your keys with one file issue. What other methods are people using to track next ID? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Monday, January 24, 2011 7:55 PM To: U2 Users List Subject: Re: [U2] Data in Dict Kate: It seems to me that this is very tidy! :-) Bill --- - Kate Stanton said the following on 1/24/2011 1:27 PM: Hi David, The reason we use dictionaries for data entry, reports, queries and forms is so we can use the same dictionary item for all activities, thus using the dictionary as designed with a little more. So, if part ID is changed at a site to be 6 numbers, then changing the dict item in a file once means the same change applies to all other activities. We think this is very tidy, and the unused portion of dictionaries have been used like this for a long, long time (over 30 years to our knowledge). Cheers, Kate Kate Stanton Walstan Systems Ltd, 4 Kelmarna Ave, Herne Bay, Auckland 1011, New Zealand Phone: +64 9 360 5310 mobile: + 64 21 400 486 fax: + 64 9 367 0750 Email: k...@walstan.com On 25 January 2011 03:53, David A. Greendgr...@dagconsulting.com wrote: All this talk about using the Dictionary item to store extra data has prompted this post. I realize in the past when the limit to the number of Opened Files in a Basic program was a programming challenge, that doing creative data storage might have been an necessity. But I would like to suggest we leave the Dictionary alone, let the database use it the way it wants to and let us create our own storage device for dictionary related data. Thoughts? David A. Green (480) 813-1725 DAG Consulting ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Data in Dict
My preference is to have a data file specifically for next key records with the item id being the filename and field 1 being the next available key. As far as restoring it should it become corrupted a fairly simple Uvbasic program which is fed a list of filenames, selects each file BY.DSND @ID, readnext, add 1 to the first key, write that as the next key for the file, next filename should be able to restore your next key file in a couple minutes if not less. George Gallen wrote: The one down side I can think of to not keeping 'next' values in the DICT and in a separate file, is if you have to restore the file, you will also have to restore the NEXT-FILE as well. It's not one neat package. But I have to admit, when I was setting up a MySQL structure and needed to implement a 'next' value, I went with a separate file and each row had two values, key and value, where the key was the filename and the value being the next value, and used this one file for all my 'next' placeholders, instead of writing it to the DICT, I used the filename as the key. Although, keeping all your nexts in one basket could be a problem if that file ever was corrupted, it would be difficult to reset them all to the correct values. Other than that, seems a bit of overhead to have a separate next file for each file you want to keep one on to avoid losing all your keys with one file issue. What other methods are people using to track next ID? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Monday, January 24, 2011 7:55 PM To: U2 Users List Subject: Re: [U2] Data in Dict Kate: It seems to me that this is very tidy! :-) Bill --- - Kate Stanton said the following on 1/24/2011 1:27 PM: Hi David, The reason we use dictionaries for data entry, reports, queries and forms is so we can use the same dictionary item for all activities, thus using the dictionary as designed with a little more. So, if part ID is changed at a site to be 6 numbers, then changing the dict item in a file once means the same change applies to all other activities. We think this is very tidy, and the unused portion of dictionaries have been used like this for a long, long time (over 30 years to our knowledge). Cheers, Kate Kate Stanton Walstan Systems Ltd, 4 Kelmarna Ave, Herne Bay, Auckland 1011, New Zealand Phone: +64 9 360 5310 mobile: + 64 21 400 486 fax: + 64 9 367 0750 Email: k...@walstan.com On 25 January 2011 03:53, David A. Greendgr...@dagconsulting.com wrote: All this talk about using the Dictionary item to store extra data has prompted this post. I realize in the past when the limit to the number of Opened Files in a Basic program was a programming challenge, that doing creative data storage might have been an necessity. But I would like to suggest we leave the Dictionary alone, let the database use it the way it wants to and let us create our own storage device for dictionary related data. Thoughts? David A. Green (480) 813-1725 DAG Consulting ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Jeff Schasny - Denver, Co, USA jschasny at gmail dot com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Data in Dict
Jeff, That's a nice simple solution, I'd just add don't forget to right justify the @ID Dict item in the file that's being selected by.dsnd ;) Allen On 1/25/2011 11:37 AM, Jeff Schasny wrote: My preference is to have a data file specifically for next key records with the item id being the filename and field 1 being the next available key. As far as restoring it should it become corrupted a fairly simple Uvbasic program which is fed a list of filenames, selects each file BY.DSND @ID, readnext, add 1 to the first key, write that as the next key for the file, next filename should be able to restore your next key file in a couple minutes if not less. George Gallen wrote: The one down side I can think of to not keeping 'next' values in the DICT and in a separate file, is if you have to restore the file, you will also have to restore the NEXT-FILE as well. It's not one neat package. But I have to admit, when I was setting up a MySQL structure and needed to implement a 'next' value, I went with a separate file and each row had two values, key and value, where the key was the filename and the value being the next value, and used this one file for all my 'next' placeholders, instead of writing it to the DICT, I used the filename as the key. Although, keeping all your nexts in one basket could be a problem if that file ever was corrupted, it would be difficult to reset them all to the correct values. Other than that, seems a bit of overhead to have a separate next file for each file you want to keep one on to avoid losing all your keys with one file issue. What other methods are people using to track next ID? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Monday, January 24, 2011 7:55 PM To: U2 Users List Subject: Re: [U2] Data in Dict Kate: It seems to me that this is very tidy! :-) Bill --- - Kate Stanton said the following on 1/24/2011 1:27 PM: Hi David, The reason we use dictionaries for data entry, reports, queries and forms is so we can use the same dictionary item for all activities, thus using the dictionary as designed with a little more. So, if part ID is changed at a site to be 6 numbers, then changing the dict item in a file once means the same change applies to all other activities. We think this is very tidy, and the unused portion of dictionaries have been used like this for a long, long time (over 30 years to our knowledge). Cheers, Kate Kate Stanton Walstan Systems Ltd, 4 Kelmarna Ave, Herne Bay, Auckland 1011, New Zealand Phone: +64 9 360 5310 mobile: + 64 21 400 486 fax: + 64 9 367 0750 Email: k...@walstan.com On 25 January 2011 03:53, David A. Greendgr...@dagconsulting.com wrote: All this talk about using the Dictionary item to store extra data has prompted this post. I realize in the past when the limit to the number of Opened Files in a Basic program was a programming challenge, that doing creative data storage might have been an necessity. But I would like to suggest we leave the Dictionary alone, let the database use it the way it wants to and let us create our own storage device for dictionary related data. Thoughts? David A. Green (480) 813-1725 DAG Consulting ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Data in Dict
At a previous employer, we used a single file similar to what Jeff suggests, and it was a very neat and tidy little file. The only problem we ran into was when we started getting larger sites, and had trouble with throughput. It turned out that with 20 or so next-item counters in one frame, the lock table became a bottleneck. We had to radically over-size the file to spread the items into more groups so that group update locks didn't hamper performance. So our neat and tidy modulo 7 or 11 file went to a modulo of around 101. Still relatively small with a separation of 1. With disk as cheap as it is these days, it's a very easy solution, once you know. Richard Lewis On Tue, Jan 25, 2011 at 10:49 AM, Allen Egerton aeger...@pobox.com wrote: Jeff, That's a nice simple solution, I'd just add don't forget to right justify the @ID Dict item in the file that's being selected by.dsnd ;) Allen On 1/25/2011 11:37 AM, Jeff Schasny wrote: My preference is to have a data file specifically for next key records with the item id being the filename and field 1 being the next available key. As far as restoring it should it become corrupted a fairly simple Uvbasic program which is fed a list of filenames, selects each file BY.DSND @ID, readnext, add 1 to the first key, write that as the next key for the file, next filename should be able to restore your next key file in a couple minutes if not less. George Gallen wrote: The one down side I can think of to not keeping 'next' values in the DICT and in a separate file, is if you have to restore the file, you will also have to restore the NEXT-FILE as well. It's not one neat package. But I have to admit, when I was setting up a MySQL structure and needed to implement a 'next' value, I went with a separate file and each row had two values, key and value, where the key was the filename and the value being the next value, and used this one file for all my 'next' placeholders, instead of writing it to the DICT, I used the filename as the key. Although, keeping all your nexts in one basket could be a problem if that file ever was corrupted, it would be difficult to reset them all to the correct values. Other than that, seems a bit of overhead to have a separate next file for each file you want to keep one on to avoid losing all your keys with one file issue. What other methods are people using to track next ID? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Monday, January 24, 2011 7:55 PM To: U2 Users List Subject: Re: [U2] Data in Dict Kate: It seems to me that this is very tidy! :-) Bill --- - Kate Stanton said the following on 1/24/2011 1:27 PM: Hi David, The reason we use dictionaries for data entry, reports, queries and forms is so we can use the same dictionary item for all activities, thus using the dictionary as designed with a little more. So, if part ID is changed at a site to be 6 numbers, then changing the dict item in a file once means the same change applies to all other activities. We think this is very tidy, and the unused portion of dictionaries have been used like this for a long, long time (over 30 years to our knowledge). Cheers, Kate Kate Stanton Walstan Systems Ltd, 4 Kelmarna Ave, Herne Bay, Auckland 1011, New Zealand Phone: +64 9 360 5310 mobile: + 64 21 400 486 fax: + 64 9 367 0750 Email: k...@walstan.com On 25 January 2011 03:53, David A. Greendgr...@dagconsulting.com wrote: All this talk about using the Dictionary item to store extra data has prompted this post. I realize in the past when the limit to the number of Opened Files in a Basic program was a programming challenge, that doing creative data storage might have been an necessity. But I would like to suggest we leave the Dictionary alone, let the database use it the way it wants to and let us create our own storage device for dictionary related data. Thoughts? David A. Green (480) 813-1725 DAG Consulting ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Data in Dict
I'm like Jeff. I prefer a separate file and routine for generating sequential numbers. This allows for prefixing, suffixing, formatting, padding, and validation of the numbers from one bit of code. Certainly there is always the issue of what happens when a file becomes corrupted, but that's what backups are for. -K ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Data in Dict
This problem might also disappear as hardware gets faster. John Israel Senior Programmer/Analyst Dayton Superior Corporation 1125 Byers Road Miamisburg, OH 45342 -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Richard Lewis Sent: Tuesday, January 25, 2011 1:18 PM To: U2 Users List Subject: Re: [U2] Data in Dict At a previous employer, we used a single file similar to what Jeff suggests, and it was a very neat and tidy little file. The only problem we ran into was when we started getting larger sites, and had trouble with throughput. It turned out that with 20 or so next-item counters in one frame, the lock table became a bottleneck. We had to radically over-size the file to spread the items into more groups so that group update locks didn't hamper performance. So our neat and tidy modulo 7 or 11 file went to a modulo of around 101. Still relatively small with a separation of 1. With disk as cheap as it is these days, it's a very easy solution, once you know. Richard Lewis On Tue, Jan 25, 2011 at 10:49 AM, Allen Egerton aeger...@pobox.com wrote: Jeff, That's a nice simple solution, I'd just add don't forget to right justify the @ID Dict item in the file that's being selected by.dsnd ;) Allen On 1/25/2011 11:37 AM, Jeff Schasny wrote: My preference is to have a data file specifically for next key records with the item id being the filename and field 1 being the next available key. As far as restoring it should it become corrupted a fairly simple Uvbasic program which is fed a list of filenames, selects each file BY.DSND @ID, readnext, add 1 to the first key, write that as the next key for the file, next filename should be able to restore your next key file in a couple minutes if not less. George Gallen wrote: The one down side I can think of to not keeping 'next' values in the DICT and in a separate file, is if you have to restore the file, you will also have to restore the NEXT-FILE as well. It's not one neat package. But I have to admit, when I was setting up a MySQL structure and needed to implement a 'next' value, I went with a separate file and each row had two values, key and value, where the key was the filename and the value being the next value, and used this one file for all my 'next' placeholders, instead of writing it to the DICT, I used the filename as the key. Although, keeping all your nexts in one basket could be a problem if that file ever was corrupted, it would be difficult to reset them all to the correct values. Other than that, seems a bit of overhead to have a separate next file for each file you want to keep one on to avoid losing all your keys with one file issue. What other methods are people using to track next ID? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Monday, January 24, 2011 7:55 PM To: U2 Users List Subject: Re: [U2] Data in Dict Kate: It seems to me that this is very tidy! :-) Bill --- - Kate Stanton said the following on 1/24/2011 1:27 PM: Hi David, The reason we use dictionaries for data entry, reports, queries and forms is so we can use the same dictionary item for all activities, thus using the dictionary as designed with a little more. So, if part ID is changed at a site to be 6 numbers, then changing the dict item in a file once means the same change applies to all other activities. We think this is very tidy, and the unused portion of dictionaries have been used like this for a long, long time (over 30 years to our knowledge). Cheers, Kate Kate Stanton Walstan Systems Ltd, 4 Kelmarna Ave, Herne Bay, Auckland 1011, New Zealand Phone: +64 9 360 5310 mobile: + 64 21 400 486 fax: + 64 9 367 0750 Email: k...@walstan.com On 25 January 2011 03:53, David A. Greendgr...@dagconsulting.com wrote: All this talk about using the Dictionary item to store extra data has prompted this post. I realize in the past when the limit to the number of Opened Files in a Basic program was a programming challenge, that doing creative data storage might have been an necessity. But I would like to suggest we leave the Dictionary alone, let the database use it the way it wants to and let us create our own storage device for dictionary related data. Thoughts? David A. Green (480) 813-1725 DAG Consulting ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman
Re: [U2] Data in Dict
In some cases I am becoming a fan of UUIDs for db table keys. A UUID
type one uses the mac address of the host along with the current time
as salt so you don't have to worry about key collisions between
accounts (I.e. TEST and PROD). Generating the next key is fast because
there is no readu, update, write. They should hash pretty well since
they are long and random.
On 1/25/11, Bill Haskett wphask...@advantos.net wrote:
Jeff:
I have a single file named (CTRLNOS) with the item ID equal to the file
name using the sequence#. Field#1 is the last seq# used while field# 2
is the maximum seq# allowed before the seq# is reset to 0. Each item
has documentation in it to describe what it's for and any unusual pieces
of data allowed (e.g. maximum length of data allowed in a text box).
The get-next-sequence code looks like:
READ{U} SEQREC FROM SEQFILE, FILENAME ELSE
SEQREC = 0:@AM:9:@AM:@AM:@AM
SEQREC := ** Item created on :TIMEDATE():.
END
SEQ = SEQREC1 + 0
MAX.SEQ = SEQREC2 + 0
OSW = 0
LOOP
SEQ += 1
IF SEQ MAX.SEQ THEN
IF NOT(OSW) THEN OSW = 1 ; SEQ = 1
END
READV{U} DoesExist FROM FILENAME.FV, SEQ, 0 ELSE DoesExist = 0
UNTIL NOT(DoesExist) DO REPEAT
If a file goes bad then I know which item to fiddle with. Just a thought.
Bill
Jeff Schasny said the following on 1/25/2011 8:37 AM:
My preference is to have a data file specifically for next key records
with the item id being the filename and field 1 being the next
available key. As far as restoring it should it become corrupted a
fairly simple Uvbasic program which is fed a list of filenames,
selects each file BY.DSND @ID,
readnext,
add 1 to the first key,
write that as the next key for the file,
next filename
should be able to restore your next key file in a couple minutes if
not less.
George Gallen wrote:
The one down side I can think of to not keeping 'next' values in the
DICT and in a separate file, is if you have to restore the file, you
will also have to restore the NEXT-FILE as well. It's not one neat
package.
But I have to admit, when I was setting up a MySQL structure and
needed to implement a 'next' value, I went with a separate file and
each row had two values, key and value, where the key was the filename
and the value being the next value, and used this one file for all my
'next' placeholders, instead of writing it to the DICT, I used the
filename as the key.
Although, keeping all your nexts in one basket could be a problem if
that file ever was corrupted, it would be difficult to reset them
all to the correct values. Other than that, seems a bit of overhead
to have a separate next file for each file you want to keep one on
to avoid losing all your keys with one file issue.
What other methods are people using to track next ID?
-Original Message-
From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-
boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Monday, January 24, 2011 7:55 PM
To: U2 Users List
Subject: Re: [U2] Data in Dict
Kate:
It seems to me that this is very tidy! :-)
Bill
---
-
Kate Stanton said the following on 1/24/2011 1:27 PM:
Hi David,
The reason we use dictionaries for data entry, reports, queries and
forms is so we can use the same dictionary item for all activities,
thus using the dictionary as designed with a little more.
So, if part ID is changed at a site to be 6 numbers, then changing
the
dict item in a file once means the same change applies to all other
activities.
We think this is very tidy, and the unused portion of dictionaries
have been used like this for a long, long time (over 30 years to our
knowledge).
Cheers, Kate
Kate Stanton
Walstan Systems Ltd,
4 Kelmarna Ave, Herne Bay, Auckland 1011, New Zealand
Phone: +64 9 360 5310 mobile: + 64 21 400 486 fax: + 64 9 367 0750
Email: k...@walstan.com
On 25 January 2011 03:53, David A. Greendgr...@dagconsulting.com
wrote:
All this talk about using the Dictionary item to store extra data
has
prompted this post.
I realize in the past when the limit to the number of Opened Files
in a
Basic program was a programming challenge, that doing creative data
storage
might have been an necessity. But I would like to suggest we leave
the
Dictionary alone, let the database use it the way it wants to and
let us
create our own storage device for dictionary related data.
Thoughts?
David A. Green
(480) 813-1725
DAG Consulting
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] Data in Dict
All this talk about using the Dictionary item to store extra data has prompted this post. I realize in the past when the limit to the number of Opened Files in a Basic program was a programming challenge, that doing creative data storage might have been an necessity. But I would like to suggest we leave the Dictionary alone, let the database use it the way it wants to and let us create our own storage device for dictionary related data. Thoughts? David A. Green (480) 813-1725 DAG Consulting ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Data in Dict
My thoughts exactly. We have a perfectly good database here, why not use it. Storing data in a dictionary has always been a bad idea, even the ubiquitous next.available record key. David A. Green wrote: All this talk about using the Dictionary item to store extra data has prompted this post. I realize in the past when the limit to the number of Opened Files in a Basic program was a programming challenge, that doing creative data storage might have been an necessity. But I would like to suggest we leave the Dictionary alone, let the database use it the way it wants to and let us create our own storage device for dictionary related data. Thoughts? David A. Green (480) 813-1725 DAG Consulting ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Jeff Schasny - Denver, Co, USA jschasny at gmail dot com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Data in Dict
My experience with the Pick O/S - database of nearly 40 years has taught me that once you truly understand it's power you stop trying to change it. Sent from my iPhone Tom Dodds t...@ix.netcom.com 630.235.2975 On Jan 24, 2011, at 9:12, Jeff Schasny jscha...@gmail.com wrote: My thoughts exactly. We have a perfectly good database here, why not use it. Storing data in a dictionary has always been a bad idea, even the ubiquitous next.available record key. David A. Green wrote: All this talk about using the Dictionary item to store extra data has prompted this post. I realize in the past when the limit to the number of Opened Files in a Basic program was a programming challenge, that doing creative data storage might have been an necessity. But I would like to suggest we leave the Dictionary alone, let the database use it the way it wants to and let us create our own storage device for dictionary related data. Thoughts? David A. Green (480) 813-1725 DAG Consulting ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Jeff Schasny - Denver, Co, USA jschasny at gmail dot com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Data in Dict
Next available is not a good example that came from the system. The previous functions like entroc supported next available and it used the dictionary field NEXT.AVAILABLE. From: t...@ix.netcom.com Date: Mon, 24 Jan 2011 10:30:49 -0600 To: u2-users@listserver.u2ug.org Subject: Re: [U2] Data in Dict My experience with the Pick O/S - database of nearly 40 years has taught me that once you truly understand it's power you stop trying to change it. Sent from my iPhone Tom Dodds t...@ix.netcom.com 630.235.2975 On Jan 24, 2011, at 9:12, Jeff Schasny jscha...@gmail.com wrote: My thoughts exactly. We have a perfectly good database here, why not use it. Storing data in a dictionary has always been a bad idea, even the ubiquitous next.available record key. David A. Green wrote: All this talk about using the Dictionary item to store extra data has prompted this post. I realize in the past when the limit to the number of Opened Files in a Basic program was a programming challenge, that doing creative data storage might have been an necessity. But I would like to suggest we leave the Dictionary alone, let the database use it the way it wants to and let us create our own storage device for dictionary related data. Thoughts? David A. Green (480) 813-1725 DAG Consulting ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Jeff Schasny - Denver, Co, USA jschasny at gmail dot com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Data in Dict
Hi David, The reason we use dictionaries for data entry, reports, queries and forms is so we can use the same dictionary item for all activities, thus using the dictionary as designed with a little more. So, if part ID is changed at a site to be 6 numbers, then changing the dict item in a file once means the same change applies to all other activities. We think this is very tidy, and the unused portion of dictionaries have been used like this for a long, long time (over 30 years to our knowledge). Cheers, Kate Kate Stanton Walstan Systems Ltd, 4 Kelmarna Ave, Herne Bay, Auckland 1011, New Zealand Phone: +64 9 360 5310 mobile: + 64 21 400 486 fax: + 64 9 367 0750 Email: k...@walstan.com On 25 January 2011 03:53, David A. Green dgr...@dagconsulting.com wrote: All this talk about using the Dictionary item to store extra data has prompted this post. I realize in the past when the limit to the number of Opened Files in a Basic program was a programming challenge, that doing creative data storage might have been an necessity. But I would like to suggest we leave the Dictionary alone, let the database use it the way it wants to and let us create our own storage device for dictionary related data. Thoughts? David A. Green (480) 813-1725 DAG Consulting ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Kate Stanton Walstan Systems Ltd 4 Kelmarna Ave, Herne Bay, Auckland 1011, New Zealand Phone: + 64 9 360 5310 Mobile: + 64 21 400 486 Email: k...@walstan.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Data in Dict
Kate: It seems to me that this is very tidy! :-) Bill Kate Stanton said the following on 1/24/2011 1:27 PM: Hi David, The reason we use dictionaries for data entry, reports, queries and forms is so we can use the same dictionary item for all activities, thus using the dictionary as designed with a little more. So, if part ID is changed at a site to be 6 numbers, then changing the dict item in a file once means the same change applies to all other activities. We think this is very tidy, and the unused portion of dictionaries have been used like this for a long, long time (over 30 years to our knowledge). Cheers, Kate Kate Stanton Walstan Systems Ltd, 4 Kelmarna Ave, Herne Bay, Auckland 1011, New Zealand Phone: +64 9 360 5310 mobile: + 64 21 400 486 fax: + 64 9 367 0750 Email: k...@walstan.com On 25 January 2011 03:53, David A. Greendgr...@dagconsulting.com wrote: All this talk about using the Dictionary item to store extra data has prompted this post. I realize in the past when the limit to the number of Opened Files in a Basic program was a programming challenge, that doing creative data storage might have been an necessity. But I would like to suggest we leave the Dictionary alone, let the database use it the way it wants to and let us create our own storage device for dictionary related data. Thoughts? David A. Green (480) 813-1725 DAG Consulting ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] Data in Dict
Thanks, Bill. What a nice thing to say! On 25 January 2011 13:55, Bill Haskett wphask...@advantos.net wrote: Kate: It seems to me that this is very tidy! :-) Bill Kate Stanton said the following on 1/24/2011 1:27 PM: Hi David, The reason we use dictionaries for data entry, reports, queries and forms is so we can use the same dictionary item for all activities, thus using the dictionary as designed with a little more. So, if part ID is changed at a site to be 6 numbers, then changing the dict item in a file once means the same change applies to all other activities. We think this is very tidy, and the unused portion of dictionaries have been used like this for a long, long time (over 30 years to our knowledge). Cheers, Kate Kate Stanton Walstan Systems Ltd, 4 Kelmarna Ave, Herne Bay, Auckland 1011, New Zealand Phone: +64 9 360 5310 mobile: + 64 21 400 486 fax: + 64 9 367 0750 Email: k...@walstan.com On 25 January 2011 03:53, David A. Greendgr...@dagconsulting.com wrote: All this talk about using the Dictionary item to store extra data has prompted this post. I realize in the past when the limit to the number of Opened Files in a Basic program was a programming challenge, that doing creative data storage might have been an necessity. But I would like to suggest we leave the Dictionary alone, let the database use it the way it wants to and let us create our own storage device for dictionary related data. Thoughts? David A. Green (480) 813-1725 DAG Consulting ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users -- Kate Stanton Walstan Systems Ltd 4 Kelmarna Ave, Herne Bay, Auckland 1011, New Zealand Phone: + 64 9 360 5310 Mobile: + 64 21 400 486 Email: k...@walstan.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
