Yes it won't matter on text or note datatypes because they all end (as far as Rbase is concerned) at the occurrence of the first null character. I can't say the same for BSTR, but that is only on the 64 bit version.
BSTR has it's length recorded as the first bit offset before the beginning of the data. Nulls can be included within the data. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Adrian > Hüssy > Sent: Monday, March 09, 2015 10:01 AM > To: RBASE-L Mailing List > Subject: [RBASE-L] - AW: [RBASE-L] - Re: SGET best practices > > I do like Karen does. > > I use max length to load rest till end of the string. > > Regards, Adrian > > > > Von: [email protected] [mailto:[email protected]] Im Auftrag von Karen > Tellef > Gesendet: Samstag, 7. März 2015 15:38 > An: RBASE-L Mailing List > Betreff: [RBASE-L] - Re: SGET best practices > > > > I always do the equivalent of SGET (..... 1000) even though my line is > nowhere near 1000. > Haven't seen an issue yet, but I guess it doesn't mean there couldn't > be in the future. > > If there are several columns in the text file, all at a fixed field > position, is there a reason why you aren't separately putting the > fields into the column in your "load" command? > > Karen > > > > > > -----Original Message----- > From: Doug Hamilton <[email protected]> > To: RBASE-L Mailing List <[email protected]> > Sent: Fri, Mar 6, 2015 5:30 pm > Subject: [RBASE-L] - SGET best practices > > This is a question on best practices and prudent programming. > > I'm importing > text data from a Big Company for updating a client's item table. > It's a fixed > field text file and the specs for the data file specify max line length > of 700 characters. > The test file I'm using is 15K lines (8.5 Mb). > I import the data > into a temp table: > > CREATE TEMP TABLE `RawPkgSpecTmp` + > (`RowNbr` INTEGER, > + > `PkgSpecData` TEXT (700), + > `ColLength` = (SLEN(PkgSpecData)) > INTEGER) > > AUTONUM RowNbr IN RawPkgSpecTmp USING 1 > > --Load data > LOAD > RawPkgSpecTmp FROM PkgSpec.TXT + > AS FORMATTED USING PkgSpecData 1 700 > > I > cursor through the RawPkgSpecTmp table a row at a time for processing, > loading the column PkgSpecData into the variable vPkgSpecData, then > using SGETs to extract relevant data. > > Most of the rows are 446 characters, I assume there's a CR at the end > of the data, not position 700. > Occasionally the data length > is 668 characters and there is a clump of data at position 661 that I > need. > > So the question is: > Is it safe to always do a SET VAR vXtraPartNbr = > > (SGET(.vPkgSpecData,8,661)) even if there are only 446 characters in > > vPkgSpecData? > > Or, for safety, should I check the length of the row > first: > IF vColLength = 668 THEN > SET VAR vXtraPartNbr = > (SGET(.vPkgSpecData,8,661)) > ENDI > to make sure I'm not wandering off into the data-hinterlands that could > back to bite me someday? > R:Base doesn't seem to > mind - vXtraPartNbr is an expected null when the data is short and > there aren't any apparent issues, messages or error messages. > > Just asking, > FMI. > Doug > p.s. This question came about because I was getting "Out of Dynamic > > Space" errors. The error was related to a subsequent command and > totally unrelated to the SGET. But it got me wondering... > > --- RBASE-L =======================3D=======================3 D= TO POST A MESSAGE TO ALL MEMBERS: Send a plain text email to [email protected] (Don't use any of these words as your Subject: INTRO, SUBSCRIBE, UNSUBSCRIBE, SEARCH, REMOVE, SUSPEND, RESUME, DIGEST, RESEND, HELP) =======================3D=======================3 D= TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [email protected] In the message SUBJECT, put just one word: INTRO =======================3D=======================3 D= TO UNSUBSCRIBE: Send a plain text email to [email protected] In the message SUBJECT, put just one word: UNSUBSCRIBE =======================3D=======================3 D= TO SEARCH ARCHIVES: Send a plain text email to [email protected] In the message SUBJECT, put just one word: SEARCH-n (where n is the number of days). In the message body, place any text to search for. =======================3D=======================3 D=
