>>>>>>Is there a way to programmaticly determine the network address of the box hosting the sql server my app is connected to? ( assuming the connection string is obfuscated within the app ) ?
>>>>>
>>>>>Google [sql server ip address]. Looking at a few of the hits, they seem to rely on running the IPConfig command-line utility via the xp_cmdshell extended stored procedure (which you may not have permission to run).
>>>>
>>>>I could set the permissions for that, but I was hoping there was something magical the app could extract from the connection without actually deciphering the connection string.
>>>>
>>>>Looks like it will just be easier to make the path a setting in the app itself and either set it manually through interface or have the app set it in the routine that locates the server on install. I will need to setup that folder and it's permissions on the server anyway, so I guess that will be the cleanest ( the install, the server etc are all completely under my control ) Just wanted to learn a trick if i could ( and the command line thing may come in handy - I'll look it up .)
>>>>
>>>>Thanks.
>>>
>>>Out of curiosity, why do you care where it's running?
>>
>>This is an app that fills in PDF forms with data for insurance policies. I'm using iTextsharper to fill the collection of PDFs, then munge them together into one big PDF that is the policy. The PDF forms are stored in the SQL database as bytearrays ( varbinary(max) ) and then streamed out to a temp file as needed and filled in. ( different policies require a different collection of forms ) Originally I was bringing the pdf templates into a temp dir ( Path.GetTempPath() + "TempPDFTemplate" ) etc for the templates and another for the output (filled PDFs) to be joined. Works fine on the LAN ( each policy has 50 - 80 pdfs ) but when connected over VPN is a lot slower.
>>
>> I'm hoping that if all the files except the last, big one can be dealt with on the server without bringing them over the wire it will improve performance, so I want to point the tempfiles and output to a folder there.
>>
>>Kind of a cool app and the client loves it, but likes to be able to dial in from home and fill out policies and wants the same response.
>>
>>We'll see.
>
>Wow. I had to do the same thing with ACORD forms about 6-7 years ago...

Did putting the temp output on the server help?