'--- Set session ---
Set ns = New NotesSession
Set db = ns.CurrentDatabase
'--- Get Profile document ---
Call GetProfileDoc(pdoc, db)
'--- Get import path --
fileName = pdoc.pWkPathCorpOnline(0)
fileNum = Freefile()
delimiter = ","
'--- Start import ---
k = 1
Open fileName For Input As fileNum%
Do While Not Eof(fileNum%)
Line Input #fileNum%, txt$
chm = Split(txt$, delimiter)
Set nDoc = db.CreateDocument
nDoc.Form = "fWkInfo"
nDoc.sRptGenDate = Now
nDoc.sPCName = Replace(Trim$(chm(0)), {"},"")
nDoc.sPatchVer = Replace(Trim$(chm(3)), {"}, "")
Call nDoc.ComputeWithForm(False, False)
Call nDoc.Save(False, False)
k = k + 1
Loop
Close filenum%
However, there is an error that states “Subscript out of range for nDoc.sPatchVer = Replace(Trim$(chm(3)), {”}, “”).
The date that I wished to retrieve will be from chm(3) onwards. I’ve even tried chm(1) to see if there’s anything wrong but still give me the same subscript error.
The following is what the CSV file will contain.
PCName,“Thu, 01 Nov 2007 23:26:03 +0000”,telnet:1009,49,ZBOL,CND,FYK,C,A,WS,12/10/2007 8:56,ZBO
You are using fileNum to get a file handle. That’s OK, but you have to refer to it consistently. Either use fileNum or fileNum% but don’t mix them. In terms of style, I prefer the former.
Always use “option declare” in the options section of your code.
The variant chm will, in theory, contain an array of 12 elements when you have completed your ‘split’ operation.
Clearly it doesn’t, as you get an error when you try to use a reference to the nth element. You should be checking for this possibility.
The input file exists, because otherwise you would not be able to open it (you would get an error at the Open keyword).
A reasonable possibility is that the input file does not contain the data you are anticipating.
Consider using the excellent lotusscript debugger to pinpoint your problem - you will be able to check the contents of each variable as you step through the code.
On another note: I recommend that you Always use option declare in code. This means you have to explicitly define each variable. Yes, it’s more code, but it makes code more reliable and readable. Do not use % to define integers, $ to define strings etc.
For what it’s worth, I always do imports in two passes. Pass 1 runs through the input file, checking that it looks OK. For example, do all the records contain 12 elements? Pass 2, the import, only runs when pass 1 is complete and the file looks OK. It takes a bit longer, but the extra processing has never been an issue. The extra reliability is good, though . . .
Subject: RE: Subscript out of range - Import CSV File
“8. Consider using the excellent lotusscript debugger to pinpoint your problem - you will be able to check the contents of each variable as you step through the code.”
I almost feel like commenting on “excellent”, but I’ll rather keep to myself … the important bit is to use it, whenever some script doesn’t seem to do what it is expected to.
“9. On another note: I recommend that you Always use option declare in code. This means you have to explicitly define each variable. Yes, it’s more code, but it makes code more reliable and readable. Do not use % to define integers, $ to define strings etc.”
Except when defining constants, where you don’t have another way to provide a data type. A constant without a $ suffix will be of type variant. Still, there is no excuse to not use option declare.
One more note: Personally, I find file handling using the NotesStream object much more straight forward and easy to handle, than using all this over-complicated filenum stuff.
Final note: “ns”, “db” or “pdoc” sound like perfectly fine variable names to me. Not so much “k” …
Subject: RE: Subscript out of range - Import CSV File
Hm . . . You made me think . . . about constants. Checking in the debugger, a string constant without the the “$” suffix is created as a CONST STRING. a string constant with the “$” suffix is created also as a CONST STRING. It seems from the help that that the data type of a constant is inferred only from the value placed in it. Not that it matters a great deal, but it does mean that as far as I can see there is no need to use the suffix system at all. It’s largely a matter of personal taste, I guess, but I find that using suffixes detracts from clean code.
Subject: RE: Subscript out of range - Import CSV File
Well, funny enough, I did not come up with this unless I saw my constants reported as Variants in LSDoc. I then debugged my code and the constants were definitely reported to be Variants indeed. I dislike suffix notation as well.
Looks like the behavior might be inconsistent. Right not, I’ve been unable to reproduce my former findings, neither in actions, agents nor ScriptLibraries. However, other evidence of the problem was with an agent accessing Oracle data, that a colleague of mine wrote some time ago. She also reported, that the agent didn’t run, unless she added the $ suffix to a constant that was passed to Oracle.
I did update from 7.0.2 to 7.0.3 in the meantime, so I wonder if this might really have been a bug. Weired.
You start the process of rectifying this error by examining the array chm() and the variable txt$ in the debugger to see what values these variables actually contain. Then determine how they came to contain those values.
I also suggest you use Option Declare, as Simon Boulton suggested. I also suggest using Option Compare Nocase.
Also I suggest using meaningful names as variable names I cringe every time I see variables such as ns and db. The worst is “s” for NotesSession. Just try searching your code for all the places you’re referencing a NotesSession when your session is named “s”… or how about trying to find “i” for an index. It’s very bad form.
Here are some standard names I use…
When referencing a NotesSession I use Nsess.
When referencing a NotesUIWorkspace I use Nuiws.
When referencing the current database I use ThisDB and ThisUIDB.
When referencing the current document I use ThisDoc and ThisUIDoc.
Variable names can be up to 40 characters long and I tend to use them. Samples are:
ConfigurationProfile (NotesDocument)
KeywordsView (NotesView)
KeywordsVEC (ViewEntryCollection)
KeywordsVE (ViewEntry)
KeywordsColl (NotesDocumentCollection)
KeywordsDoc (NotesDocument)
The point is that there’s no advantage whatsoever to using short cryptic variable names. It just makes your code hard to read and follow.