Thanks Bob

>Like not all email servers are alike, Some like AOL automatically zip large and multiple file together. and AOL has been know to trap all internet traffic on port 25 to make sure that all email goes through their server - and thus zipped into larger (smaller files)

>Another trouble with Email in general, is that some isp, limit the size of files being transmitted, and stored, so if the users are not consious, of what they have stored, they oftentimes use up their 5 megs of space, and sending dbf files, that could be used up quite quickly.

Hmm good points but since we will be sending the DBFs in Zips anyway hopefully the server will not botther compressing them still further. The data we are sending zips to very small files so size will not be a problem.


Your comments on FTP are all valid:) which is why its the primary method we will be using for the distribution of these files. The Email system is only being used as a backup system because we have to provide more than one internet mechanism for the transfer. Our other fallback system involves motorcycle couriers and floppy disks:)

The planned utitlity program IJCCOM sit between the various parts of our IJC suite of applications and removes the need for users of these applications to be part of our WAN.
These are some of the objectives I lifted from the specification.

2.1. Provide a file/document transfer utility that can work independently of any existing system but can provide that system with the ability to transfer documents from point to point.
2.2. The system should be capable of making these transfers using FTP file Transfers, Email, or T&E’s Wan if it is available.
2.3. The system should be able to switch between transparently between these methods to cover for circumstances where a particular route is closed to due to prevailing conditions.
2.4. The System should also maintain a log of despatched/received items and be capable of running in the background to inform of items as they arrive


Many Thanks for the input:)



>
>Enough for why email is not - in my opinion is not the most valid solution.
>
>As a suggestion to what would be more valid.
> FTP
>FTP is stable,
>FTP is avail on any OS
>FTP does not require the use os MAPI
>You can automate FTP process with a few different vfp class's including but not limimited to Microsoft's internet transfer control (active x) West Wind has a free version of a FTP contol as well, or you can script even the command line ftp - included with windows.
>
>you could set up some file server, as a storehouse for this process, where the clients automatically ftp'd files up to the server, and then you (processed them) put them back up on a area on the server, for downloading, and then, every so often, the client software could check for new version of of your dbf's
>
>Or, and I am really getting off the course here, ... I would set up some sql server, and make this application a internet application, where the data is live all the time. and no need to transer dbf's anywhere. just live data.
>
>
>>All comments most gratefully received:)
>>
>>
>>This thread is carried over from the thread
>>Re: Nigel Coates MAPI Class or Outlook class which should I use
>>because Nigel answered the original question.
>>
>>I am hoping to write an application that transfers Zipped DBFs as attachments.
>>
>>The idea behind the application is the my app will pass these DBFs back and forth beween remote locations using the Email system without any involvement in the process required by the user.
>>
>>Ideally the user will remain completly unaware of what is happening. New data will just start to appear in his app every so often.
>>
>>The application would be distrbuted to hundreds of external contractors and they would use it to receive tenders/works orders from ourselves and use it to complete these tenders/works orders and return the information on them to ourselves.
>>
>>The main advantages and disadvantages of the differing methods seem to be as follows.
>>
>>1. SMPT Control
>>
>>Advantages.
>>By using just classes that deal with SMTP the application will be acessible to the widest possible number of users. SMTP classes will not care what email client the user is using because it will be not be using it.
>>SMTP will be around forever just about.
>>
>>Disadvantages
>>Corporate users may not be able to connect to the SMTP server through their firewall. I cant find any stuff on receiving SMTP mail that has a VFP slant.
>>ie I might have to do it all myself:(
>>
>>2. MAPI Control
>>
>>Advantages.
>>Many users will have a MAPI complient Email client but there is chance this may change in the forseable future (Office XP according to our network guys)
>>The users will not require MS Outlook on their PCs
>>
>>Disadvantages
>>There may be a problem in trying to retrieve an attachment when those attachments are stored in MS Exchange rather than on the PC it self. HELP!
>>
>>3. Outlook Control
>>Advantages
>>Using the Outlook control provides access to the Outlook folders so the mail can be deleted after the attachments have been read. This will provide a much tidier solution for the user than MAPI.
>>
>>Disadvantages
>>All the people who use the system must also have MS Outlook on their machine so there are licence issues involved even assuming that they are happy to have Outlook sitting there upsetting their existing mail system:(
>>
>>There are a few of us trying to achieve this in UT at present and a good discussion in this area will open this technique up to many.
>>
>>Thanks
>>
>>Mark