accessing VFP data for ASP.net pages

We had (gone now) a developer who wanted to have access to our VFP tables
(several hundred mb worth) for "live" queries on a low-traffic web site.
His solution, doing all his development in ASP.net, was to create duplicate
tables on an SQL server and import the VFP data on a schedule which allowed
as up-to-date data for the queries as was possible (perhaps every 15
minutes, but no less than once an hour).

I objected to this scheme as being inefficient in that it moved many
thousands of times the amount of needed data across our various links (a
shared 10 mb pipe to the web server was the bottleneck), when he could have
accessed the data directly from ASP.net using OLEDB.

His only point was that this allowed him to use SQL stored procedures.

Can anyone give opinions on the pros and cons of these 2 approaches?

Thanks.

Gene
Thu May 05 14:58:25 CDT 2005

On Thu, 5 May 2005 13:48:44 -0400, "Chip Orange"
<acorange@worldnet.att.net[removeme]> wrote:

>We had (gone now) a developer who wanted to have access to our VFP tables
>(several hundred mb worth) for "live" queries on a low-traffic web site.
>His solution, doing all his development in ASP.net, was to create duplicate
>tables on an SQL server and import the VFP data on a schedule which allowed
>as up-to-date data for the queries as was possible (perhaps every 15
>minutes, but no less than once an hour).

What solution? I do see a problem that was masquerading as a
solution.

>I objected to this scheme as being inefficient in that it moved many
>thousands of times the amount of needed data across our various links (a
>shared 10 mb pipe to the web server was the bottleneck), when he could have
>accessed the data directly from ASP.net using OLEDB.

Quite.

>His only point was that this allowed him to use SQL stored procedures.

So does using data one day/week/month old.

>Can anyone give opinions on the pros and cons of these 2 approaches?

Pros Cons
---------------------------------------------

Developer's Approach None Several

Your Approach Several Minimal*

*I do not count upsetting a developer as a con worth considering
in most circumstances.

More importantly, what is a developer doing with live data?

Unless he is testing something that directly relates to
particular data, he has no need for live data.

I use a system that I also support. When I am testing changes, I
use old data. When I have my developer hat on, I do not need
up-to-date data except when I am recovering from a bug, and usually,
not even then.

>Thanks.

You are welcome.

Sincerely,

Gene Wirchenko

Anders
Fri May 06 04:29:31 CDT 2005

You can get at VFP data directly through VFPOLEDB and the complete SQL
language of VFP, which vast greatly enhanced in VFP9. If you need xbase
procedures to tackle tricky stuff you can now put the code in a VFP dabase's
stored procedures. The new function SETRESULTSET will transfers a VFP cursor
created in a VFP stored procedure or program back to an ADO resultset in a
single call. You can also return an XML string.
-Anders

"Chip Orange" <acorange@worldnet.att.net[removeme]> wrote in message
news:O#9KprZUFHA.3312@TK2MSFTNGP09.phx.gbl...
> We had (gone now) a developer who wanted to have access to our VFP tables
> (several hundred mb worth) for "live" queries on a low-traffic web site.
> His solution, doing all his development in ASP.net, was to create
duplicate
> tables on an SQL server and import the VFP data on a schedule which
allowed
> as up-to-date data for the queries as was possible (perhaps every 15
> minutes, but no less than once an hour).
>
> I objected to this scheme as being inefficient in that it moved many
> thousands of times the amount of needed data across our various links (a
> shared 10 mb pipe to the web server was the bottleneck), when he could
have
> accessed the data directly from ASP.net using OLEDB.
>
> His only point was that this allowed him to use SQL stored procedures.
>
> Can anyone give opinions on the pros and cons of these 2 approaches?
>
> Thanks.
>
>
>

Chip
Fri May 13 15:29:06 CDT 2005

Thanks Anders (and Gene) for your replies.

Anders, yes, I realize it can be done, I was looking for definite pros or
cons to one approach or the other that I might present to my boss. I would
like to know if duplicating the data on the SQL server, just as a for
instance, has additional security for the web server being exposed to the
world, or in some other way offers a compensation or justification for the
constant amount of data being copied to it in order to keep it
up-to-the-minute.

Thanks again,

Chip


"Anders Altberg" <x_pragma@telia.com> wrote in message
news:urpd13hUFHA.1404@TK2MSFTNGP09.phx.gbl...
> You can get at VFP data directly through VFPOLEDB and the complete SQL
> language of VFP, which vast greatly enhanced in VFP9. If you need xbase
> procedures to tackle tricky stuff you can now put the code in a VFP
dabase's
> stored procedures. The new function SETRESULTSET will transfers a VFP
cursor
> created in a VFP stored procedure or program back to an ADO resultset in a
> single call. You can also return an XML string.
> -Anders
>
> "Chip Orange" <acorange@worldnet.att.net[removeme]> wrote in message
> news:O#9KprZUFHA.3312@TK2MSFTNGP09.phx.gbl...
> > We had (gone now) a developer who wanted to have access to our VFP
tables
> > (several hundred mb worth) for "live" queries on a low-traffic web site.
> > His solution, doing all his development in ASP.net, was to create
> duplicate
> > tables on an SQL server and import the VFP data on a schedule which
> allowed
> > as up-to-date data for the queries as was possible (perhaps every 15
> > minutes, but no less than once an hour).
> >
> > I objected to this scheme as being inefficient in that it moved many
> > thousands of times the amount of needed data across our various links (a
> > shared 10 mb pipe to the web server was the bottleneck), when he could
> have
> > accessed the data directly from ASP.net using OLEDB.
> >
> > His only point was that this allowed him to use SQL stored procedures.
> >
> > Can anyone give opinions on the pros and cons of these 2 approaches?
> >
> > Thanks.
> >
> >
> >
>