John: Thanks much. I agree with ... was it Bill Downall? ... that if you don't need to add or subract it, text is a good way to go. And I'm a big fan of sequential Invoice/ PO/ WO/ SO numbers without concatenation of any other object; because they're very easy to audit. Text is perfect. Concatenation of Julian dates WOULD be very helpful in a document and/or event tracking system, where a date added to a note flag would have intrinsic meaning.
Now, to my other life. bruce/safesectors > -------- Original Message -------- > Subject: [RBASE-L] - RE: Large integer values in Rbase v8 > From: "John Engwer" <[email protected]> > Date: Sat, July 11, 2009 8:09 am > To: [email protected] (RBASE-L Mailing List) > > > Bruce, > You could use a text field to assign invoice numbers without noticeable > impact to system performance. In one of my vertical applications I have a > table of UPC codes that is accessed heavily during production. Some of my > clients have as many as 2 million UPCs in the table and access is lightning > fast. UPCs are made up of 12 or 13 numeric characters but I have them > assigned as a text value in the table. > > If you append the Julian date as the invoice number you still must assign an > invoice number in case the customer has two or more invoices on the same day. > John > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Bruce Chitiea > Sent: Friday, July 10, 2009 5:04 PM > To: RBASE-L Mailing List > Subject: [RBASE-L] - RE: Large integer values in Rbase v8 > > Bill: > > Thanks for the warning. > > But I rather think I'll know what I'm doing by then. > > bruce/safesectors > > > -------- Original Message -------- > > Subject: [RBASE-L] - RE: Large integer values in Rbase v8 > > From: Bill Downall <[email protected]> > > Date: Fri, July 10, 2009 12:40 pm > > To: [email protected] (RBASE-L Mailing List) > > > > > > On Fri, Jul 10, 2009 at 3:31 PM, Wills, Steve <[email protected]> wrote: > > > > > The cool thing is that (CTXT(JDATE())) used in this way still sorts > > > exactly like INTEGER and DATE values. > > > > > > > > > > > > > Ahh, but be warned: this will lead to serious problems when we roll over to > > 5-digit years. the year 9999 will sort *after* the year 10000. It will be > > known as the Y10K problem. > > > > Bill
