God to know that there are more undisciplined people then me Out of habit I have lot of numbers as text (project number, account number klientnumber ......) that now and are suddenly integer in the Variable. Since I am Lazy ( I know I should be more careful)and if I can help on this I am grateful
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Alastair Burr Sent: den 22 november 2002 19:37 To: [EMAIL PROTECTED] Subject: Re: Labels Dennis, Sounds like a very good idea to me. All sorts of advantages jump to mind but stopping the use of the same variable name for different variable types might also be useful. Every so often I find that I've used vXYZ as text somewhere and integer somewhere else - even when I've used some sort of naming convention that ought to stop that little boo-boo! Regards, Alastair. ----- Original Message ----- From: "Dennis McGrath" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, November 22, 2002 3:19 PM Subject: RE: Labels > Tom, > > >>This functionality and the requirement has been there since the first > >>release of R:BASE version 6.5. > > I have had a brainstorm (I think.) > > My opinion, the database should contain all it needs to unload, or be > maintained without outside code. > > We can define views, forms, reports, etc to contain global variables. > > Wouldn't it be wonderful if we could also define variable definitions that > would be stored in the database? That way they become an integral part of > the database and we could never forget to define these required variables. > Unloads would never trip over missing global variables. > > The variable(s) would be created, when necessary, every time the database > was opened. > The default value would only be supplied upon creation. > Those defined to be NOT NULL would never be allowed to be set to NULL. > CLEAR VAR or CLEAR ALL VAR would not destroy it. > We could LIST STATICVAR to see what static variables are defined. > DROP STATICVAR varname would remove the definition. > > We could say, for example: > > CREATE STATICVAR vStartDate DATE = (.#DATE) NOT NULL > vStartDate is always present, defaults to today, and cannot be set to null. > > CREATE STATICVAR vTemp TEXT > vTemp is always present, but does not have any default value and can be > NULL. > > I think this would be an incredible enhancement. Could I hope for it in > 6.5? 7.0? > > Feedback anyone? > > --Dennis McGrath > > > ================================================ > TO SEE MESSAGE POSTING GUIDELINES: > Send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: INTRO rbase-l > ================================================ > TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: UNSUBSCRIBE rbase-l > ================================================ > TO SEARCH ARCHIVES: > http://www.mail-archive.com/rbase-l%40sonetmail.com/ ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/ ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
