Problem with File Not Found Error

[Ferdalizer]

Friends,

I am writing a program that takes a standard Tab Delimited Data file and creates a table from the long header names. It creates a file called MakeDBF.prg, which I then "Do MakeDBF.prg". When I use Set Step On and debug the executable from the command window in VFP 9.0, all works fine. the MakeDBF.prg runs and creates the correct table for the data. If I run the Executable from a shortcut or Windows Explorer (both as administrator) the program throws a "File MakeDBF.prg Not Found" even though I see the file created and it is in the correct place and formatted correctly. Why would it work during debugging but not during run-time? It's probably painfully obvious but I am not seeing it. Please help.

Thanks in advance.

Fred Fattore

 

[Mike Lewis]

It's probably painfully obvious but I am not seeing it

It's not at all obvious to me. It looks like it should work the same in both environments.

Are you sure the file is "in the right place"? In the bit of your program that creates the PRG, do you specify a specific path or directory for it? And, if so, are you specifying the same path or directory when you DO the PRG? If you are relying on the file being created in the default directory, could it be that the default directory at run time is not the same as the one in your development environment?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Ferdalizer]

Hi Mike,

I watch the directory very closely and the file is in the right place. I set the default to the working directory and use the path in the DO command. During debugging I check the current directory just before the DO command is executed and it is correct. I have checked the path to make sure there are no other MakeDBF.prg files though the program should be checking the default or current directory first before exploring the path. See below.

INFILE = GETFILE('TXT')
TMPPATH = JUSTPATH(INFILE)
SET DEFAULT TO (TMPPATH)
CD (TMPPATH)

TMPPRG = (TMPPATH)+'\MAKEDBF.PRG'

TFILE = FCREATE(TMPPRG)

**Loop to fputs() content of .PRG

FCLOSE(TFILE)

CD (TMPPATH) (this is probably redundant)

DO (TMPPRG)

Do you see anything I am missing?

Thanks!

Fred Fattore

 

[Mike Lewis]

Hmm. Sorry, I can't see what is wrong with your code.

In fact, you've got several redundant lines (your SET DEFAULT and both CDs), but that doesn't explain the problem.

Also, I'd be dubious about relying on the user to select the directory in this case. What if they cancel out of the File Open dialogue, or choose a directory to which you don't have write permission? But I am assuming that's not the case while you are testing the program.

Has your EXE got an error handler? If so, try putting a command in it that will display the contents of TMPPRG when the error occurs (a MESSAGEBOX() would be sufficient).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

And if you haven't got an error-handler, you could wrap your [tt]DO (TMPPRG)[/tt] in a TRY / ENDTRY:

TRY
  DO (TMPPRG)
CATCH
  MESSAGEBOX(TMPPRG)
ENDTRY

This will tell you exactly what file the EXE is trying to find.

Just to be clear, you would do this in EXE version only, and only do it temporarily. As soon as you have the information, put it back to where it was before.

Mike




__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Ferdalizer]

Mike,

Yes, I added the redundancy when the error started popping up. Trying to cover all the bases. In developement mode, I can clearly see the current directory is correct. I will try the messagebox() in the executable and see what it tells me. I will keep you posted.

Thanks!

Fred Fattore

 

[DSummZZZ]

Maybe I'm missing something, but you first create the file, then you CD (TMPPATH). After you have changed directory, you are possibly no longer in the same directory as 'MAKEDBF.PRG'?
Or maybe TMPPATH needs a call to ADDBS()?


-Dave Summers-

Even more Fox stuff at:

http://www.dave-summers.net/foxprolinks.htm

 

[Ferdalizer]

Mike,

I added the message boxes JUST before THE DO command.

=MESSAGEBOX(TMPPRG)
TMPDIR = SYS(5)+SYS(2003)
=MESSAGEBOX(TMPDIR)

The file I am choosing is s:\jobs\14865\1\14865-1PS.TXT

TMPPRG is S:\JOBS\14865\1\MAKEDBF.PRG
TMPDIR is S:\JOBS\14865\1

So the above is all correct.

I just ran JUST the form, without my MAIN.PRG which contains all my reads and environment variables and calls the FORM. The form worked flawlessly. Since this program is for my analysts I needed an EXE in order for others to be able to use it without having to install VFP on their machine. My config.fpw is very simple. I will keep researching.

Thanks!

Fred Fattore

 

[Mike Lewis]

Or maybe TMPPATH needs a call to ADDBS()?

Dave, I thought that as well, but then I tested Fred's code, and it seems to be OK in that respect.

That said, I would prefer to use FORCEPATH() in cases like this. But I don't think that would solve the problem.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Fred,

That information is helpful, but it slightly misses the point.

What you really need is [tt]MESSAGEBOX(TMPPRG)[/tt] immediately before [tt]DO (TMPPRG)[/tt]. Since the DO is failing to find the file, that is the point where you need to check the path and name of the file.

By the way, I realise what I said before about TRY/ENDTRY was more complicated than it needed to be. Just a simple MESSAGEBOX() on its own, as indicated above, would serve the purpose.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[JackTheC]

If I understand correctly, you are doing something like this example

fpat='f:\mynew.prg'
txt="messagebox('"+time(1)+"')"
strtofile(txt,fpat)
do (fpat)

But the path (in this example f:\) is in your program not hardcoded.

If you run your program in the IDE your MakeDBF.prg is compiled and the resulting FXP is placed in another location, (in the example f:\)
If you compile your program to an EXE, your MakeDBF.prg or MakeDBF.FXP cannot be found. The path is unknown to the compiler. MakeDBF is not included in the EXE.
So when you run the executable it can't find the MakeDBF.FXP. Executables can only work with compiled programs.
If for some reason your program still works is that because of leftovers from your previous testing. In a real environment on an other PC it can't work.
(In the example the time shown is always the same, the time of the compilation not the execution)

B.t.w. I think it is strange programming: Creating an PRG on the fly and run it. I can't think of any situation that a problem can not be dealt with in your actual program.

 

[Olaf Doschke]

Why don't you use EXECSCRIPT or run the fxp after COMPILE (tmpprg).

Also, initally you talked about a windows shortcut pointin got a PRG, PRG has no association on a computer without VFP installed.

Bye, Olaf.

 

[Ferdalizer]

Jack and Olaf,

Thanks for the great insights. COMPILE worked like a charm.

Jack, I am creating the .PRG on the fly due to the myriad of file structures that we deal with on a day to day basis. These structures use long field names and I needed to shorten these to unique usable table field names while retaining the original field name information for display and manipulation. Perhaps you can suggest a way to do this without creating a .PRG for table creation?

Again, I appreciate everyone input.

Fred Fattore

 

[Olaf Doschke]

You don't need compile if you simply use the whole PRG as the script parameter of EXECSCRIPT.

Aside of that names you compose can be set via macro substitution, no need to write out a PRG for useg a name you decide at runtime only.

The very usual and useful case is for naming a cursor with the name a caller wishes:

LPARAMETERS tcALIAS
SELECT ... INTO CURSOR (tcALIAS)

The same applies to DBF file names. And of course the name expression doesn't depend on being a parameter, you may put in year and month in names and create table with a a name in a preset variable.

lcThismonthTable = Textmerge("Table<<LEFT(DTOS(DATE()),6)>>.DBF")
CREATE TABLE (lcThismonthTable) (...)

lcALIAS = JUSTSTEM(lcThismonthTable)
SELECT * FROM (lcALIAS) ...

Bye, Olaf.

 

[JRB-Bldr]

This answer does not address your initial "File Not Found Error" problem, but instead your secondary problem of:

I am creating the .PRG on the fly due to the myriad of file structures that we deal with on a day to day basis.

You should not have to be "creating the .PRG on the fly".
With a good application design you should be able to 'feed' it any changes you need and it will handle them correctly without the need for PRG modification.

You do not indicate how/where those "file structures that we deal with on a day to day basis" are available.
Typically you design your application to 'read' those files and determine their structures and then utilize them in whatever way is needed.

For example: If these files are CSV files, they typically have a 'header' row at the top.​

Your application can do a low-level read of the header row and then 'know' what to do with the data that follows.​

If you have a fixed number of standardized file structures, then it is easy to design your code to handle each one as needed in its own 'standardized' manner. I had to do that with data files from about 12 individual government agencies (each with their own 'standardized' file formats) and it worked just fine.

If each and every one of the file structures is totally different, then your code will need to be more complex - perhaps having a separate 'reference' data table to hold the shortened field names (for manipulation purposed) and their associated long field names (for display purposes).

Perhaps with a different application architecture, you can alleviate many of your issues.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

I agree, in the sense of JRB-Bldr you wouldn't even have month data tables at all. One database holding all data with a date or datetime column and you can get any months data from it. The only reason to split would be enormouse amounts of data per month. And massive data would also be a reason to move to any SQL Serve.

Bye, Olaf.

 

[Ferdalizer]

Gentlemen,

I have taken your advice and created a method to create the table structure string in memory and then used EXECSCRIPT() to create the table. My thanks! It is much more efficient.

As to the different structures, we have perhaps 50 to 60 clients that all have their own structures and those customers can change month to month along with the structures depending on who is compiling the data for us to process. Each job and subsequent files are kept in separate job directories and are unique to each job. 90% of these jobs fail to get as high as 100,000 records. A very small percentage can be very large, as high as 1,000,000 records, usually averaging out at around 40,000 records.

Fred Fattore

 

[Olaf Doschke]

I'm not in your shoes, so I can't do a specific judgement about what you should do. From what you describe roughly I understand your company offers some data analysis service you do for many customers with each a different data structure. It seems you're not having the market share to demand certain data formats and standards from your clients like any webservice would do, so your problem may not become different anytime soon. But if you don't set and demand some standards, this will continue to diversify and become a bigger and bigger mess and hell to maintain.

May it be your unique selling proposition to offer a service of data mining for any customer with a certain type of data, say product and sales data. It's not a good business model, if time necessary for manual intervention before automatic processes can run surpasses a threshold of not having enough time to maintain and enhance your service itself. That's a general thought about that.

There are business models, that work with totally varying data structures: If you are a database vendor and your customers are developers developing their individual databases, that would be such a model. But a business application with a certain topic, eg a shop system, should not be so dynamic, that it loses its coherence. You have to offer customization, if you want to attract customers not wanting the 101 shop system - put in any type of business app here - they can get as freeware open source software, but giving too much freedom you lose your control about the product, and that's in nobodys interest, as the long term fate of such a too free system is to split at some point.

Bye, Olaf.

 

[JRB-Bldr]

I agree 100% with Olaf:

if you don't set and demand some standards, this will continue to diversify and become a bigger and bigger mess and hell to maintain. It's not a good business model.

And, as a Business Model, allowing your 50 to 60 clients to all have their own file structures is unsustainable.
And to allow them to create these various file structures all on their own "depending on who is compiling the data for us to process" is equally unsustainable.

Your company needs to establish some submittal file standards (even if there are multiple ones) and supply them to your customer base and/or publish it for new customers so that they can comply no matter "who is compiling the data for us to process"

Obviously you would initially assist them in making this change to a 'standardized' submit file format (or formats) with advice/suggestions until they learn to get it right.

Alternatively you can offer your customers the option of converting their various file formats for them for a separate Add-On Charge/Fee - unless, of course, what you currently charge them isn't already so high that it already includes a built-in fee like this.
But the point is to make submittal file conversion a totally separate operation within your organization and not an integral part of application execution.

If you have to go that later route, you can have a less-skilled employee spend time converting submitted files to one of your 'standardized' formats and leave your more-skilled programmers free to not have to modify application code each time.

Good Luck,
JRB-Bldr