Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Difficulty in locating a file 1

Status
Not open for further replies.

Jerim65

Technical User
Aug 8, 2010
99
0
0
AU
In my app which uses a 3rd party app's tables I am having difficulty in identifying when a file in a particular folder is listed in a table i have created of the used file names.

I suspect the length of the path is the problem.

A typical path is in path field is

P:\_TEST_PROJECTS\MY_GOOD V7\FILES\24 TORONTO ROAD 3.JPG

I have the table of file names from the target folder and a table of all such files used in the 3rd Party app.

As the numbers of files are small ( < 5000) I have used LOCATE to test whether a folder file is in the 3rd party table.

But I do not get a FOUND() = .t. when I run the LOCATE command when I should.

I tried to introduce an idx with the command

Index On pathfieldname To here

but I get the message - invalid length of index when I run it in the command window.

How can I get this to work please?

Coldan



 
I have now located the problem.

The locate works with a local drive but a path such as

\\NASSERVER209\USERDATA\FILES\COLDAN\TEST\GENIW0015.JPG

does not work.

Is there any way to overcome this please.

Coldan
 
Based on the error you're getting from the INDEX command I'm guessing you're trying to index a memo field. Is that correct?

(Memo fields can't be indexed, because they don't evaluate to a consistent length, unless you wrap the index expression in o PADR() but DON'T DO THAT! There's almost certainly a better way.)

LOCATE can fail for many reasons. What, EXACTLY, is the LOCATE command that is failing?
 
Index have a limit of 240 bytes. In collation sequence machine you can index up to c(240) fields and in other collating sequences you can only index c(120) fields.

So far about the technical index problem.

As you have found out the real problem is UNC vs mapped drive paths. You either need to know the mapped drive letter for a share or you need the share for a mapped drive letter.

Determine the UNC Path of drive letters with Drivetype() being 4 by this function:

Bye, Olaf.
 
To clarify: Usage is GetUNCPath("M:") to get the unc path of the mapped drive letter M:, if M: is no mapped drive the return value will be M:, otherwise you get it's UNC path of the share, eg \\serverxyz\shareabc.

Bye, Olaf
 
At the risk of being verbose after Olaf and Dans responses.

What I had working is now failing.

I have written a log file to see what is going on .. I will comment with << at the end of a line - this is a sample for one file which should be reported as used.

The table containing the actual files used in a project that I have created is LISTEXH with the full path in usedexh


Create Table ListExh (id_no n (4),usedexh c (239), missing L)
Index On Upper(usedexh) Tag fnames
SET ORDER TO fnames

The log comments as I try different SEEK and Locate commands are ( actual commands shown in [ ] with alias())

18:10:47 Exhibit File 110 from Exhibit Log P:\_TEST_PROJECTS\COLDAN_GOOD V7-LOCAL\EXHIBITS2\\GENIW0098.JPG << as file is identified in 3rd party table

18:11:36 ** P:\_TEST_PROJECTS\COLDAN_GOOD V7-LOCAL\EXHIBITS2\GENIW0098.JPG - << file path from Treedir table
18:11:36 Checking status of file from searched folder P:\_TEST_PROJECTS\COLDAN_GOOD V7-LOCAL\EXHIBITS2\
18:11:36 Seek failed
18:11:36 [Locate mytarget$Upper(usedexh)]failed in LISTEXH
18:11:36 [Locate Upper(usedexh)=mytarget] failed in LISTEXH
18:11:36 Target seek is P:\_TEST_PROJECTS\COLDAN_GOOD V7-LOCAL\EXHIBITS2\GENIW0098.JPG found - No
18:11:36 Notused P:\_TEST_PROJECTS\COLDAN_GOOD V7-LOCAL\EXHIBITS2\GENIW0098.JPG << entry in another log file
18:11:36 XXXXXXXXXXX P:\_TEST_PROJECTS\COLDAN_GOOD V7-LOCAL\EXHIBITS2\GENIW0098.JPG << end of routine for that file

I have not dealt with UNC paths yet

HTH

Coldan
 
First part solved!

I have discovered the reason why none of the above SEEK and/Or LOCATEs worked.

My concatenation of the folder part and the filename part elsewhere in the program was causing

V7-LOCAL\EXHIBITS\\WILL.DOC - note the \\

The SEEK now works.

I will now attempt the UNC problem which I have just checked and is atill not working.

Coldan
 
I also spottet the double backlash. Use ADDBS(), it only ads a BS if there is one missing, so you don't get double backlashes. It also RTRIMs the path, so you concatenate the file name correctly, so use

ADDBS(path)+filename

You should be able to get at UNC paths from the drive letters, then replace driveletter with that and you have comparable strings. UNC is not the difficulty, it's simply substituting drive letters with the network share in UNC notation.

Bye, Olaf.
 
Hi Olaf,

Thanks for all your help.

The 'bad' code was written some years ago (and not found) before I learned of addbs().

I made the changes you suggested above before my last post where the whole thing worked.

Working on UNC conversion today.

Coldan
 
Olaf ,

As I look into this I now realise that what I am starting with from the 3rd party app is a path such as

\\NASSERVER209\MYUSERDATA\EXHIBITS\COLDAN\95TH.GIF

In my code I bring the path into

loDir = Createobject("Tdir", cDir,mode)

So I need to find the drive letter if it is a mapped path and can therefore be accessed by the loDir.

Regards

Coldan
 
I don't know what your Tdir class is and dos, but I suggested the inverse: replace drive letters by the share to compare the strings. I think that's easier and more reliable, but you could also check if a path begins with \\ and you have a share that is mapped. The disadvantage is you can only do that for unc paths which are beginning with a share (eg \\server\share\). UNC paths not beginning with a share will remain unc paths, as you don't find a match.

And the whole thing will fail, if you're not at a computer for which the drive letters are mapping somewhere else.

Bye, Olaf.

 
Olaf,

From your help and the others I have worked out my problem - thanl you.

I am using faq184-4136

Coldan
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top