The SRPL is correct, it works fine. I saw this problem before I added in the SRPL. Just LISTOF(T1.RNameF & T1.RNameL) show the same cut off.
David ----- Original Message ----- From: "Claudine Robbins" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, August 26, 2002 1:22 PM Subject: RE: Limit to LISTOF Function? > Shouldn't your ,0 (replace every instance) be within your SRPL quotes > and do you have too many entries in that command? Also, shouldn't your > LISTOF second parenthesis be after RNameL? > > Claudine :) > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of David M. Blocker > Sent: Monday, August 26, 2002 1:55 PM > To: [EMAIL PROTECTED] > 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/
