Can't run reports because file locked?

[Dan Snyder]

Ken,

> What is the exact command line now?  If you
> changed "/fp/dreport" to "/fp/dreport -u",
> then you didn't add a "-u" flag, but rather
> added a filename of "-u".  You need "/fp/dreport - -u".
This fixed our problem, thank you very much.


> I don't have a recent copy of Stuart's reference.
> Perhaps there's something in context that you missed? ...
I probably did miss something.  I hope you don't think I was questioning
your response.  I was only explaining why I thought it was OK to delete the
file.  Thanks for the detailed explaination of why it's bad.


> Perhaps someone created an output processing that
> didn't exist before?
I had thought of this since one of the reports in question did have an
"empty" output processing file.  However, the creation/modification date on
the file was years ago and the system date/time is currently correct.


> Perhaps you never attempted to run a report with
> output processing while someone else was accessing
> the file in *clerk prior to yesterday?
While I can't state with 100% certainty that we COULD run this report in the
past while other users were in *clerk for the same file, knowing how central
this file is to our daily operations, it seems VERY UNLIKELY that every time
it has been run in the past that no one else was in the file.  The 2 reports
in question are run 1 to 6 times every day to print out our shop work orders
and transfer data to another filePro file.  20 people go in that file every
day and many use multiple telnet sessions and keep that file open in it's
own window all day long.  Anyway, the solution above worked and I have lots
of other work piling up, so I won't worry about figuring out for certain
what happened.


>> However, the company had it working that way
>> without any problems for 10+ years before I got
>> here.  I'm planning on replacing filePro with 
>> an off-the-shelf ERP package,
> Why?  If they've been running it for 10+ years
> without any problems, why switch?
The "without any problems" comment was in regards to people accidentally
going into a dpromenu option that they aren't supposed to be in.  The
company owners have desired to switch from filePro to an ERP system for many
years due to all the issues they've had with SCO/filePro.  I was hired
primarily for the purpose of selecting an ERP system to replace filePro and
managing it's implementation.  I did evaluate the filePro applications we
currently have prior to starting a replacement project, but I do agree with
the owners that a new system is the best option.  We are a manufacturing
company, not a software company.  We shouldn't be wasting our time, effort
and money collecting requirements, writing code and testing software for
features that are basic functionality in most off-the-shelf packages today
(CRM, Quoting, MES, inventory, accounting, customer & vendor internet
portals, payroll, HRM, etc.).  We can purchase a system that has all of
these things and then just focus our effort on customizations and/or add-ons
to fill any gaps.


>> Besides, all our filePro files would need a
>> complete redesign/recoding to fix their issues
>> anyway, redoing the menus is the least of 
>> my worries.
> What sort of issues?
The issues aren't necessarily filePro, they are with OUR filePro
applications.  Here's a small list...
1. No documentation.
2. Of the 50 database files we use, none were setup as relational!  In some
cases, the same data is entered 4 times!!!
3. No organization/standards.  
	a. For example: fields are named one way
	in the data definition, another way on the screen, a third way
	on outputs and the same data in another file could have 3 different
	names (very confusing to users)
	b. Many text data fields with random data typed in for multiple
things,
	like text2 = label text in one record, = cut length in another
record
	and shipping packaging directions in a third record.
4. Our accounting and payroll are on separate systems.  Integration is
manual data entry.
5. In the areas we do use filePro, our applications only contain about 20%
of the features we would like to use.

Thanks again to all that took the time to send out responses!

Dan Snyder
IT Manager
Mercury Electronics
717-854-9557 ext.224