Bruce, Yes I am also applying naming conventions for tables and so on. In my convention a tablename always starts with a 3 or 4 character abbreviaton f.i. CMR_Customer And all the column names of that table start with the same abbreviation (like CMR_ID), unless it is a foreign key. In this way you always capable to see to which table a column belongs and in the table it is easy to see what the foreign keys are.
In my opinion it makes applications more readable and more understandable when you have to change something afer a while. It takes a little more effort in the beginning, but as you might know the development costs are about 5% of the total costs of an application in its whole lifetime. So, it is clear where you can get your savings. Tony -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bruce A. Chitiea Sent: donderdag 23 mei 2013 16:27 To: RBASE-L Mailing List Subject: [RBASE-L] - Data Object Naming Conventions Tony: Have you found any advantage to applying that approach to a broader range of data objects e.g. t_ table tt_ temporary table vw_ view tvw_ temporary view Any drawback? Thanks Bruce -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tony IJntema Sent: Thursday, May 23, 2013 7:02 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: maximum size of VARCHAR variable limited to 32KB? Mike, I have sent an example to the dream team. I agree, you should be careful with variable declarations. That's why I have implemented years ago to make a distinction between all kind of variables. Using Rbase 9.5 64 bits there are practically no limits anymore in the length of the name (and that is really a nice feature). I make a distinction between variables which are constant in practice (like the place of the database, name of application, etc.), global variables (which can bu used throughout the whole application) and local variables. These last one are always cleared at the end of a procedure. They all start with a character per kind of variable followed by an underscore. In this way it is easy to clear the local ones. In this way my system is always as clean as possible and you always know what kind of variable you are looking at Thank you for your support Tony -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mike Byerley Sent: donderdag 23 mei 2013 0:09 To: RBASE-L Mailing List Subject: [RBASE-L] - Re: maximum size of VARCHAR variable limited to 32KB? To be honest, I don't understand the 32k limitation. I think perhaps it was put in place so that in case someone forgot to specifiy a size parameter in the StdCall declaration, the default size would be 256mb, which if there were several declarations, the memory allocation for each could total up to a couple GB in short order, which for some systems would not work so well, but so what? I would guess after you bring your system to its knees a couple times, you might be a little more careful with your declarations, which should be left up to the programmer. When working with other lower level languages, I would daresay, many people have done this precise thing a time or two, but that is to be expected as a part of the learning process. I've screwed up countless times to be sure and I will likely do it again. Crap, I might do it in just a little bit as I'm screwing around with C#/asp.net doing FileIO... phhtttt! ----- Original Message ----- From: "Tony IJntema" <[email protected]> To: "RBASE-L Mailing List" <[email protected]> Sent: Wednesday, May 22, 2013 1:33 PM Subject: [RBASE-L] - Re: maximum size of VARCHAR variable limited to 32KB? : Thank you, : : Yes, I am still encountering problems. : The 32 K is a problem : I have tried to create workaround splitting the total field up in portions : of about 30 K. : This works fine when the total length is less than about 50 K, but it does : not work aymore when the field is about 80 K : Then I am already getting problems to calculate the length of the field : using SLEN, sometimes it works sometimes there is an error message about a : lack of resources. : : So I am still looking for a solution and already have put a question to the : dream team. : : Tony : : : -----Original Message----- : From: [email protected] [mailto:[email protected]] On Behalf Of Mike Byerley : Sent: woensdag 22 mei 2013 18:57 : To: RBASE-L Mailing List : Subject: [RBASE-L] - Re: maximum size of VARCHAR variable limited to 32KB? : : It might be a 32k limitation. ISTR we were getting SRPL (as well as the : other string function) to work on Varchar in about the same timeframe as : DLCall. : : : ----- Original Message ----- : From: "Albert Berry" <[email protected]> : To: "RBASE-L Mailing List" <[email protected]> : Sent: Wednesday, May 22, 2013 11:21 AM : Subject: [RBASE-L] - Re: maximum size of VARCHAR variable limited to 32KB? : : :: It seems to me that the string is too long for the SRPL function, but :: the help doesn't specify a maximum length. Try asking RBTI for help. :: They are usually very, very good at giving a hand :: :: Albert :: :: On 21/05/2013 12:41 PM, Tony IJntema wrote: :: > It looks like this is the answer. :: > But now I am confronted with an error message :: > :: > Details are: length of the variable is 41346 bytes :: > :: > I try to perform a search - replace like: :: > :: > SET VAR V_tekst = (SRPL(.V_tekst,'E','X',0)) :: > :: > The result is: :: > :: > ERROR- Insufficient buffer space to process expressions. (2136) :: > :: > Is there a setting which I can change? :: > :: :: : :
