>>>>>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.

I figured there was a good reason.

Clients want all kinds of things, don't they? <g>

The app reminds me vaguely of one I wrote for a company in the securities business. The SEC required them to retain certain reports for a period of time. My program ran all the reports, outputting them to PDFs, and then archived them to a dedicated file server in a locked room. (You don't mess around with the SEC). At the time one of the tricky parts was emailing someone in the compliance department when the current DVD was close to full. She had one of the few keys to the locked room and would go in and change DVDs, then label and send the old one to a safe deposit box. A lot of my work has been run of the mill but for some reason I remain proud of that one.