networked multi-user app

[lifesupport]

Currently this app is a single user app and I've been asked to make it a multi-user app to be networked.

The app I working on is not a typical save and alter data type of application. It consists of several very small tables which save selections by the user from data prepared by a marketing research firm; therefore, I more or less have to keep the same format of this inherited code since files come from different sources. These selections are temporary and are used to produce a report, then they are no longer needed. The entire app uses many complex select statements so if I can avoid an even more complex naming scheme, it would be better. If two users are running the same report, they will both be using the same small selection files, thus producing a 'file in use error'. My solution is as follows but will get pretty 'harry' upon usage of field names as you can see. Is there a better way?

RELEASE pcext
PUBLIC pcext
pcext=SYS(2015)

COPY file filename.dbf TO ("filename"+ALLTRIM(pcext)+".dbf")
IF NOT used ("filename"+ALLTRIM(pcext))
USE ("filename"+ALLTRIM(pcext)) IN 0
Endif
SELECT ("filename"+ALLTRIM(pcext))
Go top
defdir=EVALUATE(("filename"+ALLTRIM(pcext)+".fieldname"))

Thanks

 

[DSummZZZ]

Start by either adding a SET EXCLUSIVE OFF statement at the beginning of your app, or by adding SHARED to any of your USE commands.
USE ("filename"+ALLTRIM(pcext)) IN 0 SHARED

-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[lifesupport]

Nice idea, but it won't work in my situation because most of these temporary files are the result of select statements pulling data from data files that are never written to. If I allow a shared atmosphere, each user will be over-writing the other user's selections.

 

[Scott24x7]

Lifesupport,
Instead of SYS(2015), why not use SYS(3), which will guarantee the user a unique file name every time? Also, if your application writes temp files to local drives, using SYS(3) it would be impossible to have a "File in ues" problem. Even on a network drive, SYS(3) within the same directory, assures the creation of a unique file every time, so a non-issue.

Or, if they are so small and you are using SELECT, why not create them as Cursor's or Arrays? Then there is no need for file issues at all...


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

Lifesupport,

To avoid users overwriting each other's temporary files, save the temp files to the user's personal Temp folder, which you can find via SYS(2023).

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[dbMark]

If the tables are used only once and within the program, then why not just create cursors, tables existing only in computer memory? No possibility others could use try to open your cursors, and they're gone when the application quits.

 

[lifesupport]

Thanks all. Cursors are a possibility. I also like the sys(2023) idea; however, will it return the temp file of the user or the temp file of the application that is running? Can't test it now - T-storm.

 

[lifesupport]

It just dawned on me that you're probably wondering why am I responding during a t-storm. It's because it's been rumbling all day and I don't want to loose a day's work, but I also don't want to loose 2 machines if it amounts to anything.

 

[Mike Lewis]

Lifesupport,

I also like the sys(2023) idea; however, will it return the temp file of the user or the temp file of the application that is running?

It will return the temp folder (not a file) of the user. This will normally be a folder in the user's personal bit of "Documents and Settings" (or equivalent in earlier versions of Windows).

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk