starting this morning the use of F6 tab to look up a customer gives the error below. This started when we had a slow remote connection. It now happens for all users regardless of security level or location. looks to be only OE module

Insufficient rights to create file in data directory

This used to be a problem when the CRF files were too many... that has been fixed. I see no crf files at all in the data base.

I don't know the reason for your error message, but I can tell you that there shouldn't be any CFR files. They are temporary files that are created when you do an F6 lookup in AR and should be deleted when you exit AR. There was a problem with an older version of AR where they were not deleted as they should have been.

Steve

Hi Bruce,

Make sure that every Adagio user has their own user ID for signing into Adagio. This error could happen if everyone signs into Adagio with the same user ID (such as SYS). The SmartFinder saves information by user, which would mean that if 2 people tried to access the SmartFinder at the same time, both users would be writing to the same file, which in ths case is a no-no and would give the error you are receiving.

That is definitely not the problem, as everyone has and uses their own ID.

Additionally, we have another data set, which uses the same information, that we do "testing" in. This data set was last overwritten in mid-February, and I went into that data set today, it is fine.

So I believe something (don't know what) is definitely "missing" from our data. I did double check, and it is indeed only OE. All other modules the F6 key works fine. As Bruce mentioned, this problem began when the system was responding extremely sluggishly.

We are still experiencing this problem. Any help?

Thank you.

Hi Barb,

What application has F6 stopped working in when looking up customers? (OrderEntry or Receivables). Do both applications pass the Data Integrity Check? (File | Data Integrity Check) If you can press F6 without generating the error, try clicking the Reset button in the Column Editor, exiting the column editor, then re-selecting the columns you'd like to have displayed.

Okay, tried suggestions. Did a DI check in O/E and in inventory. Both came up clean. The problem is really only in O/E, and it is consistent right across the board for all our users. If any of us go into O/E, click "New" to enter a new order, then, at "Customer" hit the F6 button, we all get the same message: "Critical Error: (1011) insufficient rights to create file in data directory."

Cannot access the column grid at all to try the second suggestion of resetting the column Editor.

Thanks for the continuing suggestions, I know we are going to fix this and make everyone happy. Some of our users are quite dependant on this function to get the right customer. Work around is putting in three letters, then 000 and arrowing down. You would be surprised how some people STILL want their F6 key!

Thanks very much. I will try to be patient!

Hi Barb,

Go into the data file and search for OEF???'?.dat where "dat" is your data extension. (It is often easier to do this from the command prompt.) If you are sure that no one is in OrderEntry, rename all the files that have numbers in the first 3 "???" position. That is:

Delete OEF001'I.dat and OEF001'R.dat but not OEFCTL'R.dat.

My guess is that you'll find one of the temporary numeric files with 'I but not 'R or vice versa.

Andrew, I checked our data file and the following three OEF files exist:

OEF001'I.DAT
OEFCTL'I.DAT
OEFCTL'R.DAT

Given that there are both the I and the R, what is the best way to proceed?

Thanks VERY much for the help!

It's the OEF001'I.DAT that's causing the problem. Get rid of it.

Andrew we did that & it fixed it for a moment. Like minutes. The problem has been ongoing still. I just looked & we have OEF001 - OEF004 currently.
What now happens & I believe this was the case all the way along is the 1st person to open OE & looks up using the F6 as described by Barb gets this lock...If the same person opens a 2nd copy all works perfect. The problem can move from user to user when the OE function that is messed up is closed then the next in gets it. All other users are OK as soon as one locks the problenm to themselves.

Hi Bruce,

It sounds like someone isn't exiting OrderEntry properly (or have you checked the opportunistic locking settings on your server recently?).

If no-one is in OrderEntry, then there should not be any files in the data directory that match the mask OEFnnn'I/OEFnnn'R as these are the temporary files that store the SmartFinder results during an active session.

Hi Bruce,

You should have these data files as long as someone is in the OE data. They should get cleaned up (ie deleted) when people exit OE. Every time a user performs a smart-find search on a field they haven't yet done in that session, a new file will be created.

We have heard of issues like this when users sign into Adagio with the same ID (ie SYS) rather than having a unique user ID for each user. Can you confirm that all of your users have unique sign-in codes? This is the correct way of doing things.

Within the smartfinder control (OEFCTL), this keeps track of the 'next smart finder file number'. An error could occur if for some reason this 'next number' value is not updated and wants to create say OEF001 but it is already there. I am unaware if this has ever happened before, but simply identifying the logic.

I have a data set that has OEF001-0EF022 when no one is logged into OE. Should I delete these files?

Thanks, David

If nobody is accessing the data (with OE or any other Adagio or associate program), then yes it is OK to do so.

Are you aware if these files are ever cleared out for you when users close Adagio OE? Perhaps sometimes and not other times? How many users do you have in OE ata time, and do they have unique user ID codes?

we have individual users set up for sure. there could be 6-10 users. we have cleared all the OEF files at one time & they may indeed go away each time. The 2nd & subsequent files all react correctly just the 1st one limits user function. I will check the ops locking again but I believe it is OK. just to comfirm the setting is ON or OFF?

Bruce,

If you run \softrak\system\chksys.exe on all systems, including the server, it will set the locks correctly.

Or you can follow my rule of thumb: any Microsoft default setting is wrong

Hi Bruce,

From your original post, you indicated that things work perfect when a 2nd copy is opened. From this, do you mean that a user may open a second instance of Adagio OE on the same computer, meaning that they have two windows open at the same time on the same data? This is OK to do. I ask because if SmartFinder searches are done while having 2 instances open, this could gives similar results (and problems) as if users were sharing user ID codes.

See if when people have multiple instances of OE open at the same time, whether they are performing SmartFinder searches on the same field (ie customer or item, etc) in both windows. This could potentially be the culprit.

We are experiencing two different problems. I hope I may recap. They almost seem to be related. The Order Entry problem is with the F6 key. The second problem is with Inventory, and is more frustrating. This problem also seems to be ONLY with one user at a time, almost like "Tag, you are IT." The user opens inventory, and clicks Item Inquiry. A pop up reads: "Critical Error (1011) insufficient rights to create file in data directory." If this user then exits inventory, the next person to go in will get the error. If this person keeps this copy of inventory open, and opens a second copy all is well. The first copy can be kept open all day, and the same error consistently comes up. You must click okay, and then the item looks like it is trying to load as the hourglass is there, but nothing further ever happens. All tabs that you click are utterly blank of any information. The item description remains blank, if you click on any of the tabs, such as the Sales History tab, it is completely blank. No months are even shown.

I hope this helps us nail down this problem. If I get the error I have just been making a habit of keeping that copy open, as this error frustrates the living daylights out of anyone who is trying to sell something to a customer on the phone!

Hi Barb,

When a user accesses the Item Inquiry (with Sales and Costs) function, some temporary data work files are created, and should be deleted by the program when viewing the Item is closed. We have seen that if for some reason these temporary files are not deleted properly (ie a system crash), attempting to use the Item Inquiry will give the 1011 error when it wants to create a temp file and it already exists.

First make sure that nobody is using any Adagio programs. Using Windows Explorer, browse to the data directory. Then look to see if there are any data files starting with ICH followed by 4 numbers and then a letter (such as ICH0002R.dat). If there are any data files like this and nobody is using Adagio, then these files should not be there. In that case, you can try renaming the file extension to something like 'bad' or 'xxx' for each file like this you find. Then try opening IC or OE to see if the problem still persists when using Item Inquiry.

If this works or not, please post back your results.

hey guys if you look back in this string we just did a full loop.

we have eliminated the files. this still happens.
with everone out of the system and the files gone we can replicate the error at will. The only thing I have to admit is I have not done the suggestion by Ralph Allan (thank you) which I will do tonight. If it works I will be on early to expound the virtues of P.G. & their obviously clear air.

Well I checked the Opps locks & all look to be good. The OE files have been removed that had the 001 or what ever in them & we still get the same error with F6
We can duplicate it, work around it, but we can't eliminate it.
To restate the problem we get a lack of rights error on an F6 look up for the 1st user. The subsequent users are OK as is the 2nd instance for the 1st user. If the 1st user closes out then the next person to hit F6 gets the user rights error.
all users have unique log in & varing rights.

If there are no OEF### data files in your data directory, I would not expect the first user opening Adagio OrderEntry to get an error using the SmartFinder.

Perhaps try this. When nobody is in Adagio, rename not only any OEF### data files, but also the OEFCTL'I and OEFCTL'R data files - these are the SmartFinder control files. Also rename the OEMFCT'I and OEMFCT'R data files if they exists - these are the SmartFinder control files if you have ever performed a SmartFinder search using 2 or more criteria.

When you next open OrderEntry, the OEFCTL files will be recreated. And the next time you perform a search with 2 or more criteria, the OEMFCT files will be recreated. If you continue to get the same errors after having done this, then I believe there is something in the workstation or network environment that is the ultimate cause of the problem.

Just wanted to say that I get this type of error from time to time as well, especially with a client that has about 6 to 8 concurrent OE users regularly. All users have their own IDs and to my knowledge do not use multiple instances.

Not realising that I was not meant to remove the control files, I have always moved BOTH the OEF control files AND the OEF ### files - oops. However, the good news is that moving both has always cleared up the problem for a a good length of time (usually weeks/months). As mentioned at the start of this post, however, the problem does eventually recur.

I believe (and am keeping fingers crossed for you) that not removing the Finder's control files as well was likely the problem but I await Bruce/Barb9's next post with keen interest.

Pete

Thanks for the confirmation that I am not entirely crazy. I have now eliminated the control files as per everyones instructions & the problem does not currently exist. Time will tell. Pete we had 23 users & maybe 12-15 using the OE so the number of users may have something to do with the error.
Thanks for the continued help everyone.