[AccessD] Data Export Spec - Rev1

Shamil Salakhetdinov shamil at users.mns.ru
Mon Oct 24 07:54:18 CDT 2005


> As always happens in these projects, a lot of interest is expressed, but
> that doesn't necessarily translate into active participation.
John,

I cannot promise active participation because of heavy workload but what I
promised so far - convert your code using Implements and design patterns and
a set of low coupled/highly cohesive  custom classes and/or move the
converted code to VB.NET/C# for scalability, real asynchronous execution
etc. - this is what I plan to do sooner or later...

> Also, I am not even sure that SQL Server does not have
> something similar built-in and therefore nobody using SQL Server would use
> this.
MS SQL Server has Data Transformation Services(DTS) - one may use them to
automate data export to fixed width/delimited text files. And DTS can also
generate VB6 code, and transformation/formatting VB6 code can be
written/edited during DTS Wizard helping to  prepare DTS package....

IMO you can compete with DTS if your code will have different area of
applications, which DTS doesn't cover....

Shamil

----- Original Message ----- 
From: "John Colby" <jwcolby at ColbyConsulting.com>
To: "'Access Developers discussion and problem solving'"
<accessd at databaseadvisors.com>
Sent: Thursday, October 20, 2005 3:44 PM
Subject: Re: [AccessD] Data Export Spec - Rev1


> Shamil,
>
> The modules do not have to use DAO as long as ADO provides the
functionality
> of accessing the fields using the rst(fldname) operation.  The code you
see
> is pseudocode, intended to display the concept, not the actual execution,
> and I can write DAO in my sleep so it is easy for me to write the
pseudocode
> in.  In my framework I use ADO exclusively, however I am still not
anywhere
> close to "as comfortable with it" as I am with DAO.
>
> My PREFERENCE is to use ADO throughout for widest applicability.  My
> PREFERENCE is also to get a good SQL Server person on board to keep us
> running down a path that allows immediate, built-in usage with SQL Server.
> So far I do not have a lot of hands raised saying that they want an
in-depth
> piece of the action.  Also, I am not even sure that SQL Server does not
have
> something similar built-in and therefore nobody using SQL Server would use
> this.
>
> As always happens in these projects, a lot of interest is expressed, but
> that doesn't necessarily translate into active participation.  I have
> learned to be prepared to do what needs to be done, on my own, to get what
> -I- need done.
>
> John W. Colby
> www.ColbyConsulting.com
>
> Contribute your unused CPU cycles to a good cause:
> http://folding.stanford.edu/
>
<<< tail skipped>>>




More information about the AccessD mailing list