• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 245
  • Last Modified:

Application creates files on the client not the server

Hello experts:

I've inherited a C# Windows application that when it runs on a server (win 2000), it works like a charm.
During the run it creates some text files on the server drive. These files are used at the end of the run to do a bulk insert into sql.

But when I run it from a client it outputs the text files not on the server drive but on the client's drive so the application has an exception during the bulk insert because it's looking for the text files on the server drive.

Has anybody heard of this and if so what I can do so that when I run the application from the client, it outputs the text files(needed for the bulkinsert) into the server drive not the clients's.

  • 7
  • 5
1 Solution
lancerxeAuthor Commented:
The path is defined at the @Application.StartupPath
lancerxeAuthor Commented:
If the @Application.StartupPath gets the path for the executable file that started the application, then that's why the text files are outputted on the server drive if the application is run from the server and are outputted on the client's drive when the application is run from the client.

How can I output the text files on the server drive when the application is run from the client's.?
I guess Application.StartupPath does not help me in this case.
Create two path variables, one for files to reside locally, and one for files to reside on the server, say, LocalPath and ServerPath.

During program initialization, set them both to the local path, say, StartupPath, then check to see if you're running on a server or workstation.  If the former, reset ServerPath to the appropriate UNC or with a drive mapping, if one exists.
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

Oops, that's 'latter', not 'former'.
lancerxeAuthor Commented:
Thanks cookre but I have a question.
Is there a way to determine from inside the code whether aplication is running on a server or workstation?
lancerxeAuthor Commented:
I found this VB6 code that may help me determine whether aplication is running on a server or workstation.
Am I on the right track ?

Private Declare Function GetSystemMetrics Lib "user32" (ByVal
nIndex As Long) As Long

Function IsTerminalServicesSession() As Boolean
   Dim b As Boolean

   b = GetSystemMetrics(SM_REMOTESESSION)

   IsTerminalServicesSession = b
End Function


    If (IsTerminalServicesSession()) Then
        ' It's a Terminal Server session
        ' It's local on the user's workstation
    End If

Now, why did I suspect that was coming?

This usually depends on the organization's infrastructure.

Is there a distinguishing characteristic in computer names?

Do workstations get their IPAs via DHCP and servers static?

Do workstations/servers have services/agents that servers/workstations don't (for example W3SVC (IIS))?

If there are sufficiently few servers, one can check against the actual names (poor form).

Can they be distinguished by OS version?

Can they be distinguished by drive mappings, or lack thereof?
If every time it's run on a server is via a Terminal Services session, then yes.
lancerxeAuthor Commented:
Thanks cookre.
I get the idea.
lancerxeAuthor Commented:
Hello cookre:

We are almost there.

Here's what i did.

1) I use  drive mapping to acces the server path. (y:\)
2) Modified the code to output to server path  (y:\) if running from the client.
3) It works because the History.txt files is now created on the server (mapped drive y:\).

However during the BulkInsert step, I get this error:
Error [42000] [MS Sql Server Driver] [Sql server] Could not bulk insert because file y:\History.txt could not be opened. OS System error 3(system cannot find the path specified)

The error says the path cannot be found. But how come it found the path when History.txt was created on the mapped drivey:\.
Could this be a right issue?

I'd guess it's just a normal file not found problem.

Alas, I don't know enough about MSSQL to give a good diagnosis, but a guess might be that the mapping to y was done on one box, a path containing y: was then passed to and executed on another box - that doesn't know what y: is.

If that's the case, passing a UNC would get around the problem.
lancerxeAuthor Commented:
As I suspected it was a rights issue.
Everything is working  
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

  • 7
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now