RE: [U2] call mysub vs. call @mysub
From: Brian More useful is the fact that UniVerse caches subroutine object in memory until you exit to TCL, so the overheads on repeated calling are minimised anyway. useful as long as you aren't dynamically writing/changing the code that you're calling. But then as long as the sub name isn't hardcoded you can simply compile a sub with a different name and dynamically call to the new code if required. For anyone who works with D3, the 'k' option on the compile verb tells the runtime to core-lock object modules in memory to achieve the same performance benefits described here for U2. Caching always has pros and cons, whether it's BASIC object, web pages, CSS, or some OS-level process or data. To suit our varying needs we should all have a good grasp on how to turn cache on _and_ off as required. This sort of information is elusive in this market and I've found Unidata and jBASE to be particularly problematic in this regard. Regards, T --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] 2 gig files
Hi I know this is an oft spoken of matter but this is a slightly different question. I have udt 7.1 32 bit running on a RHEL 64bit linux box. At linux I can unzip a file and it creates the resulting 10 gig csv no problem, I can then further manipulate this as I wish. If I issue the zip command from within udt the unzip fails once the resulting csv file reaches 2 gig. Anyone know of a way to execute such a command without udts limits imposed on the resulting shell ? Thanks Symeon. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UniVerse Index Files
Of course those 7 writes only occur if every trigger needs to be updated each time? Dict one = OPEN attr 2 = if open then @id else null Dict two = CLOSED attr 2 if Not(open) then null else @id Roger Dan Fitzgerald wrote: Not sure of a limit, but you will see a decrease in performance at around 6 or so (your mileage may vary, but probably not by much). Bear in mind that every write to an index file is a write. If you have 6 indexes and everything else is perfect (no splits or merges), that means that you have to do 7 writes every time you update. Subject: [U2] UniVerse Index Files Date: Tue, 26 Aug 2008 14:48:42 -0400 From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Does anyone know if there is a limit on the number of index files you can build on a UniVerse Type 30 file?AIX 5.3 uv 10.2Andrea Charles Access Manager: This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is prohibited. If you have received this e-mail in error, please immediately notify us by calling the Help Desk at (212) 999-9911 or email us at [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ _ See what people are saying about Windows Live. Check out featured posts. http://www.windowslive.com/connect?ocid=TXT_TAGLM_WL_connect2_082008 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UniVerse Index Files
Check your uvconfig file.There is a t30 limit. Looks like default is 200. Do the indexes get counted among the 200? Or are they counted separately? Roger Ray Wurlod wrote: The limit is 1000. This results from the actual index files following the naming convention INDEX.nnn starting from 000. Every index degrades update performance, so you should still be selective. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] 2 gig files
Sorry, I only use Universe. But Universe uvconfig has a ulimit option. And the system will default to either AIX ulimit or Universe, depending on which one is LARGER. Roger Symeon Breen wrote: Hi I know this is an oft spoken of matter but this is a slightly different question. I have udt 7.1 32 bit running on a RHEL 64bit linux box. At linux I can unzip a file and it creates the resulting 10 gig csv no problem, I can then further manipulate this as I wish. If I issue the zip command from within udt the unzip fails once the resulting csv file reaches 2 gig. Anyone know of a way to execute such a command without udts limits imposed on the resulting shell ? Thanks Symeon. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] UniData Keys
I am tasked with building an log file for our customers using our web site (Redback). I have figured out how to grab what I need, but am not sure the best way to make the file structure. I need to track the user (their E-mail address), the web page, the various request options, the date and time. Should I: 1) make each record a unique hit on the web (i.e. not multi-valued) with a sequential number as the key? 2) make each record a unique hit on the web (i.e. not multi-valued) with the key being the emailAddress*date*time (a big key depending on the emailAddress)? 3) make the key the emailAddress*date, with each hit that person makes a multi-value based on the time? The issue here is that while I am not storing a lot of pieces of data for each hit, some of the data will be big (emailAddress, web page). Option 2 could have a big key and I believe UniData would prefer a smaller one (half the data is the key). To take it to an extreme, since there are no multi-values, the entire key could be the record, but clearly, this is not preferred. Option 3 would take advantage of multi-values, but a user who hits a lot of pages will have a HUGE record for each day. I am leaning towards option 1 (many small records, with a sequential number as the key), but wanted to throw this out for debate. John Israel --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse Index Files
Thanks for all the info. We are using bscan to search and sort a very large file and already have 18 indices (yikes) on one file. It might be best to rewrite the app rather than adding more indices. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Wurlod Sent: Tuesday, August 26, 2008 7:00 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniVerse Index Files The limit is 1000. This results from the actual index files following the naming convention INDEX.nnn starting from 000. Every index degrades update performance, so you should still be selective. Access Manager: This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is prohibited. If you have received this e-mail in error, please immediately notify us by calling the Help Desk at (212) 999-9911 or email us at [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Updating UV/UD PE
I don't think you can get an activation key for the PE versions. IIRC it's noted in the download somewhere. The easiest way to upgrade is to: -download the new version, double check the ending date - there was a problem with a new copy not being up before the last one expired, plus there have been some issues with some recent releases -install overtop of your existing release hth Colin Alfke Calgary, Canada -Original Message- From: Tony G I need to upgrade my PE versions. I let them lapse and believe they're both dead simply because of a temp license timeout. If that's not supposed to happen, please let me know so I can do some better diagnostics. ;) If I download the latest releases, what's the easiest way to upgrade? - Complete uninstall/reboot/reinstall of everything? - Install on top of prior releases (with backups beforehand of course)? - Or is there a way to just get a new activation key for the next couple months? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse Index Files
If your code does a write, it's all updated on disk, whether or not you actually change data. Date: Thu, 28 Aug 2008 07:50:13 -0400 From: [EMAIL PROTECTED] Subject: Re: [U2] UniVerse Index Files To: u2-users@listserver.u2ug.org Of course those 7 writes only occur if every trigger needs to be updated each time? Dict one = OPEN attr 2 = if open then @id else null Dict two = CLOSED attr 2 if Not(open) then null else @id RogerDan Fitzgerald wrote: Not sure of a limit, but you will see a decrease in performance at around 6 or so (your mileage may vary, but probably not by much). Bear in mind that every write to an index file is a write. If you have 6 indexes and everything else is perfect (no splits or merges), that means that you have to do 7 writes every time you update. Subject: [U2] UniVerse Index Files Date: Tue, 26 Aug 2008 14:48:42 -0400 From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Does anyone know if there is a limit on the number of index files you can build on a UniVerse Type 30 file?AIX 5.3 uv 10.2Andrea Charles Access Manager: This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is prohibited. If you have received this e-mail in error, please immediately notify us by calling the Help Desk at (212) 999-9911 or email us at [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ _ See what people are saying about Windows Live. Check out featured posts. http://www.windowslive.com/connect?ocid=TXT_TAGLM_WL_connect2_082008 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ _ See what people are saying about Windows Live. Check out featured posts. http://www.windowslive.com/connect?ocid=TXT_TAGLM_WL_connect2_082008 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniData Keys
I would base my decision on the method of retrieval. I like the sequential key method, a lot of systems don't like the @ sign as part of the key. But if you do choose the email*date*time I would suggest turning it around and making it Date*Time*Email so that the data lines up better when listing. Thanks, David A. Green www.dagconsulting.com (480) 813-1725 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Israel, John R. Sent: Thursday, August 28, 2008 5:39 AM To: 'u2-users@listserver.u2ug.org' Subject: [U2] UniData Keys I am tasked with building an log file for our customers using our web site (Redback). I have figured out how to grab what I need, but am not sure the best way to make the file structure. I need to track the user (their E-mail address), the web page, the various request options, the date and time. Should I: 1) make each record a unique hit on the web (i.e. not multi-valued) with a sequential number as the key? 2) make each record a unique hit on the web (i.e. not multi-valued) with the key being the emailAddress*date*time (a big key depending on the emailAddress)? 3) make the key the emailAddress*date, with each hit that person makes a multi-value based on the time? The issue here is that while I am not storing a lot of pieces of data for each hit, some of the data will be big (emailAddress, web page). Option 2 could have a big key and I believe UniData would prefer a smaller one (half the data is the key). To take it to an extreme, since there are no multi-values, the entire key could be the record, but clearly, this is not preferred. Option 3 would take advantage of multi-values, but a user who hits a lot of pages will have a HUGE record for each day. I am leaning towards option 1 (many small records, with a sequential number as the key), but wanted to throw this out for debate. John Israel --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniData Keys
This dilemma came up on the SnupNow.com project. At the time, and now, I favored option one. Sometimes people change their eMail address. Consider starting the ID sequence at say 1,000 (or 10,000). If more than 9000 customers come on-board, the Ids can be back-filled with a leading zero. --Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Israel, John R. Sent: Thursday, August 28, 2008 8:39 AM To: 'u2-users@listserver.u2ug.org' Subject: [U2] UniData Keys I am tasked with building an log file for our customers using our web site (Redback). I have figured out how to grab what I need, but am not sure the best way to make the file structure. I need to track the user (their E-mail address), the web page, the various request options, the date and time. Should I: 1) make each record a unique hit on the web (i.e. not multi-valued) with a sequential number as the key? 2) make each record a unique hit on the web (i.e. not multi-valued) with the key being the emailAddress*date*time (a big key depending on the emailAddress)? 3) make the key the emailAddress*date, with each hit that person makes a multi-value based on the time? The issue here is that while I am not storing a lot of pieces of data for each hit, some of the data will be big (emailAddress, web page). Option 2 could have a big key and I believe UniData would prefer a smaller one (half the data is the key). To take it to an extreme, since there are no multi-values, the entire key could be the record, but clearly, this is not preferred. Option 3 would take advantage of multi-values, but a user who hits a lot of pages will have a HUGE record for each day. I am leaning towards option 1 (many small records, with a sequential number as the key), but wanted to throw this out for debate. John Israel --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse Index Files
The indexes are btrees and not controlled by the t30limit. Jerry Banker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Glenfield Sent: Thursday, August 28, 2008 6:45 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] UniVerse Index Files Check your uvconfig file.There is a t30 limit. Looks like default is 200. Do the indexes get counted among the 200? Or are they counted separately? Roger Ray Wurlod wrote: The limit is 1000. This results from the actual index files following the naming convention INDEX.nnn starting from 000. Every index degrades update performance, so you should still be selective. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniData Keys
I would go for #1 because the time slice may be short and cause a problem with key creation the other ways. It would create lots of records but small ones and may be faster. You can then move them into another file, periodically, deleting the single valued records and creating multi-valued ones using the email address as the key. Jerry Banker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Israel, John R. Sent: Thursday, August 28, 2008 7:39 AM To: 'u2-users@listserver.u2ug.org' Subject: [U2] UniData Keys I am tasked with building an log file for our customers using our web site (Redback). I have figured out how to grab what I need, but am not sure the best way to make the file structure. I need to track the user (their E-mail address), the web page, the various request options, the date and time. Should I: 1) make each record a unique hit on the web (i.e. not multi-valued) with a sequential number as the key? 2) make each record a unique hit on the web (i.e. not multi-valued) with the key being the emailAddress*date*time (a big key depending on the emailAddress)? 3) make the key the emailAddress*date, with each hit that person makes a multi-value based on the time? The issue here is that while I am not storing a lot of pieces of data for each hit, some of the data will be big (emailAddress, web page). Option 2 could have a big key and I believe UniData would prefer a smaller one (half the data is the key). To take it to an extreme, since there are no multi-values, the entire key could be the record, but clearly, this is not preferred. Option 3 would take advantage of multi-values, but a user who hits a lot of pages will have a HUGE record for each day. I am leaning towards option 1 (many small records, with a sequential number as the key), but wanted to throw this out for debate. John Israel --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] RE: U2UG Board Meeting - Mini Minutes - Aug 26
The U2 User Group Board met via conference call at 4:00p US Eastern time on Tuesday, August 26, 2008. In attendance were Laura Hirsh, David Jordan, Chuck Barouch, Ross Morissey and Susan Joslyn Business discussed included: 7 New logo and color scheme to refresh our image and the web-site 7 Charter amendment to provide for voting when no quorum is present. 7 The vacated position will be filled according to who was next in the vote count, with their acceptance 7 U2UG / IBM liaison still needed. Anyone attending U2U will mention to IBM staff 7 There will be a U2UG meeting at Spectrum (Denver, March 23-26), time to be determined. 7 A new idea was proposed to create a title that is awarded to people to recognize their contribution. Title ideas will be forwarded and this will be discussed again at the next meeting. 7 Carry over business 7 U2UG.COM ` U2UG.ORG 7 Board will nominate thankees and these people/companies will be added with links to the web site (Action: Board to nominate, Brian to add links.) 7 A WIKI training session will be scheduled with Brian Leach so that everyone can post wikis 7 We are still working to get an automated Better Better procedure. [Better Better is the name of the process for users to make recommendations and requests for enhancement to the U2 databases and tools and to get the weight of the user group behind those requests, vet them and take them to IBM.] We have a potential volunteer site host. Submitted by Susan Joslyn, board member at large serving as secretary. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniData Keys
There is no way you should put the email address as part of the key. You can run into key length issues, the file will not hash properly causing access to it to be slow. Based on speed which is all we care about in 911 development. We use sequential keys zero filled. Date, time and email address would be attributes 1, 2 and 3. Build an index off of the data you will access all the time. The file will hash very nicely. Just make sure your counter of keys doesn't roll over back to 1 again. My 2 cents. Nicholas M Gettino | Director of Development | EnRoute Emergency Systems, an Infor company | office: 813-207-6998 | fax: 678-393-5389 [EMAIL PROTECTED] | www.enroute911.com Register Now! | EnRoute Emergency Systems Customer Conference | September 22-25, 2008 | Mainsail Suites Hotel Conference Center | Tampa, Florida -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jpb-u2ug Sent: Thursday, August 28, 2008 10:53 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniData Keys I would go for #1 because the time slice may be short and cause a problem with key creation the other ways. It would create lots of records but small ones and may be faster. You can then move them into another file, periodically, deleting the single valued records and creating multi-valued ones using the email address as the key. Jerry Banker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Israel, John R. Sent: Thursday, August 28, 2008 7:39 AM To: 'u2-users@listserver.u2ug.org' Subject: [U2] UniData Keys I am tasked with building an log file for our customers using our web site (Redback). I have figured out how to grab what I need, but am not sure the best way to make the file structure. I need to track the user (their E-mail address), the web page, the various request options, the date and time. Should I: 1) make each record a unique hit on the web (i.e. not multi-valued) with a sequential number as the key? 2) make each record a unique hit on the web (i.e. not multi-valued) with the key being the emailAddress*date*time (a big key depending on the emailAddress)? 3) make the key the emailAddress*date, with each hit that person makes a multi-value based on the time? The issue here is that while I am not storing a lot of pieces of data for each hit, some of the data will be big (emailAddress, web page). Option 2 could have a big key and I believe UniData would prefer a smaller one (half the data is the key). To take it to an extreme, since there are no multi-values, the entire key could be the record, but clearly, this is not preferred. Option 3 would take advantage of multi-values, but a user who hits a lot of pages will have a HUGE record for each day. I am leaning towards option 1 (many small records, with a sequential number as the key), but wanted to throw this out for debate. John Israel --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] RE: U2UG Board Meeting
Consider opening these conference calls up to ordinary U2UG members. --Bill --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse Index Files
Jerry: I was under the impression that UV indexes are some kind of a linked list (e.g. each index key has all of the IDs associated with it in a single record). That's why BSCAN is needed to further process the list of IDs. Whereas, UniData (and D3) actually uses BTrees where one traverses the tree with a single function. E.g. if I want Smith, John H. I goto to Smi] and start traversing up and down with the same function as I want. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jpb-u2ug Sent: Thursday, August 28, 2008 7:56 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniVerse Index Files The indexes are btrees and not controlled by the t30limit. Jerry Banker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Glenfield Sent: Thursday, August 28, 2008 6:45 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] UniVerse Index Files Check your uvconfig file.There is a t30 limit. Looks like default is 200. Do the indexes get counted among the 200? Or are they counted separately? Roger Ray Wurlod wrote: The limit is 1000. This results from the actual index files following the naming convention INDEX.nnn starting from 000. Every index degrades update performance, so you should still be selective. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse Index Files
Yeah, 18 indices is gonna hurt; you have to open 19 files every time you open that file. If MFILES isn't pretty high (and any corresponding parameter in the OS, like nofiles in AIX), you'll be expending a lot of resources just opening closing files. Then there's the performance hit of doing about 20 physical writes every time you update a record. Subject: RE: [U2] UniVerse Index Files Date: Thu, 28 Aug 2008 08:56:38 -0400 From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Thanks for all the info. We are using bscan to search and sort a very large file and already have 18 indices (yikes) on one file. It might be best to rewrite the app rather than adding more indices. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Wurlod Sent: Tuesday, August 26, 2008 7:00 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniVerse Index Files The limit is 1000. This results from the actual index files following the naming convention INDEX.nnn starting from 000. Every index degrades update performance, so you should still be selective. Access Manager: This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is prohibited. If you have received this e-mail in error, please immediately notify us by calling the Help Desk at (212) 999-9911 or email us at [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ _ Talk to your Yahoo! Friends via Windows Live Messenger. Find out how. http://www.windowslive.com/explore/messenger?ocid=TXT_TAGLM_WL_messenger_yaho o_082008 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniData Keys
Sequential keys are ok unless you have a heavily used system as you have to read with a lock, and increment a counter somewhere - in this instance we use unique ids generated using date, system time in milleseconds (system(12) in udt) and pid combined together Symeon. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Gettino Sent: 28 August 2008 19:07 To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniData Keys There is no way you should put the email address as part of the key. You can run into key length issues, the file will not hash properly causing access to it to be slow. Based on speed which is all we care about in 911 development. We use sequential keys zero filled. Date, time and email address would be attributes 1, 2 and 3. Build an index off of the data you will access all the time. The file will hash very nicely. Just make sure your counter of keys doesn't roll over back to 1 again. My 2 cents. Nicholas M Gettino | Director of Development | EnRoute Emergency Systems, an Infor company | office: 813-207-6998 | fax: 678-393-5389 [EMAIL PROTECTED] | www.enroute911.com Register Now! | EnRoute Emergency Systems Customer Conference | September 22-25, 2008 | Mainsail Suites Hotel Conference Center | Tampa, Florida -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of jpb-u2ug Sent: Thursday, August 28, 2008 10:53 AM To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniData Keys I would go for #1 because the time slice may be short and cause a problem with key creation the other ways. It would create lots of records but small ones and may be faster. You can then move them into another file, periodically, deleting the single valued records and creating multi-valued ones using the email address as the key. Jerry Banker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Israel, John R. Sent: Thursday, August 28, 2008 7:39 AM To: 'u2-users@listserver.u2ug.org' Subject: [U2] UniData Keys I am tasked with building an log file for our customers using our web site (Redback). I have figured out how to grab what I need, but am not sure the best way to make the file structure. I need to track the user (their E-mail address), the web page, the various request options, the date and time. Should I: 1) make each record a unique hit on the web (i.e. not multi-valued) with a sequential number as the key? 2) make each record a unique hit on the web (i.e. not multi-valued) with the key being the emailAddress*date*time (a big key depending on the emailAddress)? 3) make the key the emailAddress*date, with each hit that person makes a multi-value based on the time? The issue here is that while I am not storing a lot of pieces of data for each hit, some of the data will be big (emailAddress, web page). Option 2 could have a big key and I believe UniData would prefer a smaller one (half the data is the key). To take it to an extreme, since there are no multi-values, the entire key could be the record, but clearly, this is not preferred. Option 3 would take advantage of multi-values, but a user who hits a lot of pages will have a HUGE record for each day. I am leaning towards option 1 (many small records, with a sequential number as the key), but wanted to throw this out for debate. John Israel --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.6.7/1632 - Release Date: 25/08/2008 07:05 No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.6.7/1632 - Release Date: 25/08/2008 07:05 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniData Keys
-snip- - in this instance we use unique ids generated using date, system time in milleseconds (system(12) in udt) and pid combined together Symeon. Not a bad idea, however you may encounter problems of losing data in these 2 areas: 1. As processors get faster, the difference in execution time shortens and it can be possible to generate the same key during the same millisecond. Adding a NAP 1 in my simulated testing eliminated the duplicates. On one implementation of Pick (Altos?) I recall the resolution of the system(12) function was only a second. 2. At least one time a year (in my timezone) the clock is turned back one hour and it would be possible to overwrite existing keys during that hour. -Troy --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Updating UV/UD PE
Thanks for the note Colin! From: Colin Alfke I don't think you can get an activation key for the PE versions. Does that mean that the failure of the platforms to initialize may have to do with something other than a PE license expiration? Rather, I'm understanding that a full installation is required to get the software back working, and that there is no key-only re-activation process. Is that correct? The easiest way to upgrade is to: -download the new version, double check the ending date - there was a problem with a new copy not being up before the last one expired, plus there have been some issues with some recent releases Well bud, that's not mighty encouraging. Since the versions I'm on work fine, I might be inclined to just re-install what I already have, if I could, but this whole process seems to be a waste of time. -install overtop of your existing release What I'm getting from this is that: 1) no uninstall is required, 2) files and registry entries will not be left unreferenced and services will be properly unregistered and re-registered, 3) existing accounts will be visible to an update environment. I'm sorry but I don't have that much faith in the U2 installers so some confirmation would really help. I'll check upgrade docs again but for some reason these docs always seem to over-complicate simple processes, or under-emphasize some critical concern (like of course you need to completely uninstall and re-install the UniSDK and all of your client processes after you've installed this new release...). Regards, T --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse Index Files
UV indexes are B-trees too. BSCAN allows you to traverse the leaf nodes, rather than go up and down the tree to get to the next leaf node. But you are right that, within that structure, the dynamic array of primary keys associated with a particular index key value is stored as, well, a dynamic array. It is captured into memory with a single I/O operation (ignoring overflow, which *none* of us has, right? - and even then is relatively rare in UV B-tree structures which use a buffer size of 8KB) and the linked list can then be processed at memory speeds. If you want a single function, you can have it in UniVerse. You have your choice of READ or SELECTINDEX. You don't need BSCAN unless that's what you're doing. It scans index values, not primary key values. - Original Message - From: Bill Haskett [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniVerse Index Files Date: Thu, 28 Aug 2008 11:45:33 -0700 Jerry: I was under the impression that UV indexes are some kind of a linked list (e.g. each index key has all of the IDs associated with it in a single record). That's why BSCAN is needed to further process the list of IDs. Whereas, UniData (and D3) actually uses BTrees where one traverses the tree with a single function. E.g. if I want Smith, John H. I goto to Smi] and start traversing up and down with the same function as I want. Bill --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Triggers
Chapter 5 of the 10.2 SQL Reference manual is correct. The file does not have to be SQLized, but you still have to use valid SQL syntax for the TCL commands used to CREATE and DROP them, ie., ' for literals (not ) and you must end the command with a semi-colon (;). Regards, Clif -- W. Clifton Oliver, CCP CLIFTON OLIVER ASSOCIATES Tel: +1 619 460 5678Web: www.oliver.com The information in the System Description manual is inaccurate. On Aug 27, 2008, at 8:32 AM, Tom Dodds wrote: Universe SQL Reference if I remember correctly. HTH Tom Dodds -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alspach, Vance Sent: Wednesday, August 27, 2008 8:54 AM To: u2-users@listserver.u2ug.org Subject: [U2] Triggers What manual contains information on creating Universe triggers for non-SQLized files? I cannot seem to find it in any manual UV 10.2.4 Pick format IBM RS6000 Vance Alspach CONFIDENTIALITY. This electronic mail and any files transmitted with it may contain information proprietary to Deere Company, or one of its subsidiaries or affiliates, and are intended solely for the use of the individual or entity to whom they are addressed, shall be maintained in confidence and not disclosed to third parties without the written consent of the sender. If you are not the intended recipient or the person responsible for delivering the electronic mail to the intended recipient, be advised that you have received this electronic mail in error and that any use, dissemination, forwarding, printing, or copying of this electronic mail is strictly prohibited. If you have received this electronic mail in error, please immediately notify the sender by return mail. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ __ Information from ESET NOD32 Antivirus, version of virus signature database 3392 (20080827) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Triggers
Clif, You are very correct I use a few of them on several files for auditing of my universe files. It was tough for me as well to find but then I found it they are the same commands whether its SQL tables or universe files. Make sure nobody has the file open when you create them thou. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clifton Oliver Sent: Thursday, August 28, 2008 4:07 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Triggers Chapter 5 of the 10.2 SQL Reference manual is correct. The file does not have to be SQLized, but you still have to use valid SQL syntax for the TCL commands used to CREATE and DROP them, ie., ' for literals (not ) and you must end the command with a semi-colon (;). Regards, Clif -- W. Clifton Oliver, CCP CLIFTON OLIVER ASSOCIATES Tel: +1 619 460 5678Web: www.oliver.com The information in the System Description manual is inaccurate. On Aug 27, 2008, at 8:32 AM, Tom Dodds wrote: Universe SQL Reference if I remember correctly. HTH Tom Dodds -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alspach, Vance Sent: Wednesday, August 27, 2008 8:54 AM To: u2-users@listserver.u2ug.org Subject: [U2] Triggers What manual contains information on creating Universe triggers for non-SQLized files? I cannot seem to find it in any manual UV 10.2.4 Pick format IBM RS6000 Vance Alspach CONFIDENTIALITY. This electronic mail and any files transmitted with it may contain information proprietary to Deere Company, or one of its subsidiaries or affiliates, and are intended solely for the use of the individual or entity to whom they are addressed, shall be maintained in confidence and not disclosed to third parties without the written consent of the sender. If you are not the intended recipient or the person responsible for delivering the electronic mail to the intended recipient, be advised that you have received this electronic mail in error and that any use, dissemination, forwarding, printing, or copying of this electronic mail is strictly prohibited. If you have received this electronic mail in error, please immediately notify the sender by return mail. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ __ Information from ESET NOD32 Antivirus, version of virus signature database 3392 (20080827) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniData Keys
Troy wrote: At least one time a year (in my timezone) the clock is turned back one hour and it would be possible to overwrite existing keys during that hour. For those who deal with daylight savings on unix, in the fall when clocks roll back, the clock hits 3:00am and then rolls back to 2:00am. As Troy points out, this causes that one-hour period to occur twice, possibly leading to issues with duplication. For this same reason, we never schedule any cron jobs between 2am and 3am as they would run twice. Conversely, in the spring when time rolls forward, the clock hits 2am and immediately jumps to 3am, thereby skipping any processing (eg: cron) that might've occured between 2am and 3am. Jeff Butera, Ph.D. Administrative Systems Hampshire College [EMAIL PROTECTED] 413-559-5556 He works out of his home office doing technical training. I call it gambling. Overheard at grocery store. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniData Keys
if all your looking for is a unique ID then can't you generate a GUID as the ID? this is more of a question then an answer. not that you would be able to use this to sort or order the entries. Jeffrey Lettau ERP Systems Manager polkaudio From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Buss, Troy (Logitek Systems) [EMAIL PROTECTED] Sent: Thursday, August 28, 2008 7:02 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] UniData Keys -snip- - in this instance we use unique ids generated using date, system time in milleseconds (system(12) in udt) and pid combined together Symeon. Not a bad idea, however you may encounter problems of losing data in these 2 areas: 1. As processors get faster, the difference in execution time shortens and it can be possible to generate the same key during the same millisecond. Adding a NAP 1 in my simulated testing eliminated the duplicates. On one implementation of Pick (Altos?) I recall the resolution of the system(12) function was only a second. 2. At least one time a year (in my timezone) the clock is turned back one hour and it would be possible to overwrite existing keys during that hour. -Troy --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ Disclaimer: This email may contain confidential and/or privileged information. It is intended only for the person or persons to whom it is addressed. Any unauthorized review, use, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email or telephone and destroy all copies of the original message. Please consider the environment before printing this email. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
