Yes Ron, Doesn't matter what the wrapping is set to, it still truncates at 20
David BLocker ----- Original Message ----- From: "Ron Rose" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, August 26, 2002 1:16 PM Subject: Re: Limit to LISTOF Function? > Have you tried the '=w' option with the SELECT? > RRR > > ----- Original Message ----- > From: "David M. Blocker" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, August 26, 2002 11:55 AM > Subject: Limit to LISTOF Function? > > > > Hi folks, > > > > I'm writing an application to prepare a scheduling system for a company > that > > transports special needs kids to school systems. The output desired > should > > show the name of each child, the time and place they are picked up, then > the > > "drop off" at the school, listing the kids with the school name, like > this: > > > > Name Place Time > > Ken Richards 11 Jones Ave 6:45AM > > Christopher Raymond 11 Woodland Dr. 6:50AM > > Christopher McDonald 12 Robert Ave 6:55AM > > Sarah Gardner-Dickson 110 Friend St. 7:00AM > > > > Ken Richards, Christopher Triton Regional 7:10AM > > Raymond, Christopher High School > > McDonnald, Sarah > > Gardner-Dickson > > > > I'm accomplishing this quite well with a series of SELECTs unioned > > together. I'm having one minor problem with the SELECT that produces the > > "school stop" row. I'm using this to get the list of names: > > > > SELECT (SRPL (LISTOF( T1.RNameF & T1.RNameL),',',', ',0)) FROM ...... > > > > This works great, placing a space between the names after each comma, > UNLESS > > the student's name (combined First + space + last) exceeds 20 characters, > as > > in the last name above, Sarah. For each name, I get no more than 20 > > characters, with the rest truncated. What I get is this: > > > > Ken Richards, Christopher Triton Regional 7:10AM > > Raymond, Christopher High School > > McDonnald, Sarah > > Gardner-Dickso > > > > It doesn't matter where Sarah's name falls in the list, the "N" at the end > > of her name does not print: the cut off appears to be 20 characters. > There > > is nothing at the RSyntax spot about a limitation of each item in a LISTOF > > cutting off at 20 characters, nor in the TXT file that came with that > patch. > > > > Is there a limit? If not, can I do something to force R:Base to give me > the > > full name, no matter how long it is? > > > > David Blocker > > > > ----- Original Message ----- > > From: "Troy Sosamon" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, August 26, 2002 9:42 AM > > Subject: RE: Insert Problem > > > > > > > Paul, > > > > > > Take a look at your rules. Do you have any rules on those large tables > > your > > > are inserting into? Rules and constraints on large tables can cause > some > > > serious performance problems. Steve already addressed below the > overhead > > of > > > indexes. > > > > > > Troy Sosamon > > > > > > ===== Original Message from [EMAIL PROTECTED] at 8/26/02 7:59 am > > > >Paul, I think I can help w/part of your problem. I often have to do > > INSERTs > > > >using SELECT or LOADs fm mainframe extracts, a goodly number at the > scale > > > >you describe, and have encountered that "... the process has slowed > > > >considerably". The cause is this, assuming that INDEXes are defined > > f/the > > > >table that is being INSERTed INTO, when RBase performs an INSERT/LOAD, > it > > > >builds the INDEX "on the fly", which greatly multiplies the disk I/O. > > This > > > >really bogs down the performance. > > > > > > > >So, in order to get a more satisfactory cycle-time f/such large loads, > I > > do > > > >a couple of things, some of which you might be able to try. Firstly, I > > > >create a command file to do my INSERTs/LOADs. Yea', so what? Well, > and > > > >secondarily, the what is this, I include, in addition to my INSERT/LOAD > > > >statement, a set of DROP INDEX statements and, more rarely, a DELETE > ROWS > > > >statement. Each of these is placed prior to the INSERT/LOAD statement. > > I > > > >also issue a SET RULES off command. It might also be better to do this > > with > > > >SET MULTI off, as well - I'm sure there are many other folks on this > list > > > >who can go more deeply than I into the nuance of these statements. > Now, > > > >lastly, I issue a set of (controverting) CREATE INDEX statements which > > > >re-build those INDEXes DROPped prior to the INSERT/LOAD. > > > > > > > >Now, this might seem redundant, but trust me, all else being equal, > this > > > >will reduce aggregate cycle-time by a "fer piece". I go back a long > way > > > >w/RB and I recall some programmer fm Colorado who sold his own RB > indexer > > > >utility, the source code of which, according to my recollection, was > > > >subsequently licensed by M'rim. At this point, I learned that, f/large > > > >INSERT/LOAD operations, it was more time efficient to explicitly issue > > > >CREATE INDEX statements rather than let RBase build the indices > > implicitly, > > > >according the DDL/metadata, that is, what would be defined with the > > TABLE. > > > >Believe me, (re-)building an index explicitly is WAY FAST! (This is > > > >probably true f/most decent DBMS packages.) I'm sure you could come up > > > >w/some simple tests to do comparisons. > > > > > > > >So, in short : > > > > > > > >-- DATE & TIME FORMAT/SEQUENCE settings according to extract definition > > (as > > > >necessary &&|| applicable) > > > >-- DROP INDEX statements > > > >-- DELETE ROWS (as necessary &&|| applicable) > > > >-- LOAD/INSERT statements > > > >-- CREATE INDEX statements > > > >RETURN > > > > > > > >As f/the workstation lock-up, can't offer any ideas there, short of > some > > > >sort of local/server-side timeout which is due to the excessive length > of > > > >time f/the INSERT/LOAD operation to complete. > > > > > > > >HTH, > > > >Steve in Memphis > > > > > > > > > > > >----- Original Message ----- > > > >From: <[EMAIL PROTECTED]> > > > >To: <[EMAIL PROTECTED]> > > > >Sent: Saturday, August 24, 2002 9:45 PM > > > >Subject: Insert Problem > > > > > > > > > > > >> > > > >> > > > >> I am having a problem with a 4.5++ database when doing inserts to > > > >tables. > > > >> It started with workstation lock ups when inserting rows using > "insert > > > >into > > > >> ... select ...". Now when I am running an old program that inserts > > rows > > > >into > > > >> a table, the process has slowed considerably. I recently did a pack > > and > > > >> reload without a problem. However, there are several tables > > containing > > > >> nearly a million rows and one with nearly 2.5 million rows. Any > ideas? > > > >> > > > >> Paul Hill > > > >> ================================================ > > > >> 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/ > > > > > > > > > ================================================ > > 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/
