If the file names are hard coded, then no doubt as soon as you have
concurrent users, you will run into problems.
It is very worth retrofitting this DLL, to return results of the function in
some sort of in memory format so you don't have these problems - not to
mention, so that you can avoid reading files from disk. Of course, if we are
talking about very large files being created here, then the in-memory
solution won't work. In this case, you will have to come up with a
workaround where a file name will be passed to the function, and that file
name will be unique for each user. This way each user gets their own file,
and they are not interfering with each other.
"Caroline" <(E-Mail Removed)> wrote in message
news:4D9FCF75-9747-4584-8C5B-(E-Mail Removed)...
> Thanks ahead for any suggestions.
>
> Newby question here concerning state.
>
> I am working on a protype for a web page that uses an antiquated 3rd-party
> dll. This dll was compiled with Microsoft Powerstation 4.0.
>
> My ASP application will:
>
> 1. gather data from a user and write that data to a text file on the hard
> drive
> 2.call the dll
>
> The dll reads the text file, performs some math and then writes output to
> a
> tab-delimited file.
>
> My ASP application then reads the tab-delimited file and builds some
> graphs.
>
> This works for demonstrative purposes, but I am worried that when we
> publish
> it and have several dozen users accessing it, that I will have problems
> with
> user data being overwritten or sent to the wrong user.
>
> Any information--including KBs or references to literature on this
> topic--is
> appreciated.
>
> If the current scenario--where my ap writes and reads from the hard
> drive--will work, then fine. But if it won't, I need to make a valid
> argument for recompiling the dlls so the dlls will accept arguments and
> then
> return data in memory.
|