Exporting in a dual platform environment

[Andrew Bailey]

I develop in an environment with a 50/50 mix of Macs and PCs and have many scripts that either export or save records out to a directory on a server.

On PCs, this is very straightforward: just enter the output file path and the file saves, no other interaction required. On Macs, the only way this works is if the specific drive the directory is in gets mapped to each user's computer. This is problematic for a bunch of reasons, namely that it means extra steps and we have users who regularly delete the mounted drives and then wonder why the scripts stop working.

Is there a trick for Macs that I'm just missing?

[Fitch]

http://hints.macworld.com/article.php?story=20100403050702737

Scripts steps you could use:

Perform Applescript

Open URL

Or using a plugin, you can use the OS command line.

PS: I'm pretty sure the Windows drive letters must also be mapped.

[Andrew Bailey]

Thanks! I will try these out.

On Windows, you need only map drives if you reference directories by drive letter in the script (i.e. filewin:/C:/folder/$filename), but you don't if you just enter the full path (i.e. filewin://servername/folder/$filename). 

[Wim Decorte]

1 hour ago, Fitch said:

PS: I'm pretty sure the Windows drive letters must also be mapped.

You most certainly do not... Windows supports reading from and writing to a network share through the UNC format of the share:  \\serverName\shareName\

Easy enough to translate that into FM-speak.

[Fitch]

Thanks for setting me straight. I'm not a Windows authority by any means. In our office everyone's PC is centrally managed, and network drives are all consistently mapped to drive letters, so we've gotten used to relying on that. Maybe not a good idea?

[Wim Decorte]

Good or bad depends on how users go about messing with those mapped drives.  If they don't disconnect them then you are good.

You just don't need them to interact with the network shares programmatically.  Visually is something else.  The mapped drives are visible in the Windows Explorer, making it easy on the users.

[Andrew Bailey]

23 hours ago, Fitch said:

Thanks for setting me straight. I'm not a Windows authority by any means. In our office everyone's PC is centrally managed, and network drives are all consistently mapped to drive letters, so we've gotten used to relying on that. Maybe not a good idea?

What are these "consistently mapped drive letters" you speak of? 

That's actually how I figured out that it was easier on Windows to just map a direct path rather than a drive letter. I'd go to map someone to X: because a script called for it, but they'd have something else mapped to it already.

The benefit to mapping to drive letters, I believe, would come in if you decided to replace a server. We consolidated file servers a couple years ago and it took a lot of tedious work to go into each script that called for a save and change the server name. I don't think doing it by drive letter would've caused any problems, so long as when you re-mapped everything it pointed to the same directories as before.

[Fitch]

Hmmm, so maybe referencing the drive letter in scripts is not a bad way to go after all. E.g., each user has their own personal network space, which is their "H:" drive. There have been times where that was moved to a different server. So by using the "H" reference in our FileMaker scripts rather than the specific server, the change didn't break anything for the FileMaker users. There are just a handful of other letters that we've standardized on, and users don't mess with them.