[AccessD] Deploying .net solutions

>I also suggest a terrific product called Total Commander, which is a
Windows-based "clone" + extension of Norton Commander, and includes FTP
facilities, so you could use it to get immediately to your goal, while you
experiment with the One-Click .NET technology.

My goal isn't a file manager replacement.  My goal is a program which ftps
files down to the local hard drive, unzips them, unencrypts them, and loads
them into a database.  Each such file is specific to one particular client
insurer (client of my client) and there are potentially dozens of them, a
half dozen at the moment.  Each from a different company, each coming from a
different FTP site (obviously), each formatted differently (but with
patterns which allow a generic solution).

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Friday, April 27, 2007 4:52 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Deploying .net solutions

One doesn't write applets in VB.NET, JC, but aside from that, the One-Click
technology in .NET should please you immensely. While you explore that, I
also suggest a terrific product called Total Commander, which is a
Windows-based "clone" + extension of Norton Commander, and includes FTP
facilities, so you could use it to get immediately to your goal, while you
experiment with the One-Click .NET technology.

A.


On 4/26/07, JWColby <jwcolby at colbyconsulting.com> wrote:
>
> I have a bunch of processes that are not particularly suited to Access 
> for one reason or another.  These include things like
>
> * doing what I call "directory watching" and performing some action 
> when a file appears.
> * FTP transfers between local drives and FTP sites
> * Building complex data feeds between a database and a remote 
> mainframe
>
> To take an example, I regularly build data feeds which look like:
>
> Header Rec
> Detail Rec
> Detail Rec
> Detail Rec
> .
> .
> Trailer Rec
>
> The header rec has some specific set of data in it such as who it is 
> coming from, the date of the file etc.
>
> The detail recs have repetitive data such as payments to clients, 
> payment dates, from/to dates that the payment is for, the amount, the 
> check number etc.
>
> The footer rec has some specific data in it such as the number of 
> checks, the bank account number that the checks are drawn against etc.
>
> I have built a report generator in VBA, inside of access, and it 
> works, but it is really rather patchwork by nature.  I have to 
> reference specific libs, go outside of VBA to handle things like the 
> file system and text streams (in an object oriented manner) and so 
> forth.  There are no threads so a single error can hang the system, 
> and things that should happen in parallel have to happen sequentially.
>
> So, I would like to take one of these systems and move it to .Net.  
> What I am trying to discover is how .Net systems are (reliably) 
> deployed to the desktop.  Often times these applets are used by more 
> than one person, often at the same time.  At the moment, because they 
> are Access / vba based, I just do a copy down to the desktop (a single 
> file) and open the mdb.  A form opens and the user goes to work.  
> These applets are under constant development, literally daily as I 
> finish one report another is started.  Bug fixes are done.
>
> I assume (but am not sure) that a VB.Net applet would be distributed 
> as well, downloaded to the desktop and run from there.  What is the 
> vehicle for this distribution?
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com