SCATTERing to an object from an ADO Recordset 
Author Message
 SCATTERing to an object from an ADO Recordset

Hi, thanks Beth. Last question please, would you know which performs better
under
specific conditions:

1) SQL 7 database on a separate server from web server with ASP files
accessing
data directly

or

2)SQL 7 database on a separater server, VFP COM objects on a 2nd server, and
web
server on a 3rd one with ASP files accessing data via VFP and passed thru
with
the solution you recommended.

Thank you very much, I'll buy you coffee next time we meet. You're the
greatest!


Quote:
> You can disconnect the recordset from the server and then pass the entire
> recordset back to the ASP page. ADO marshals itself better than an object
> you create anyways. ADO transports itself across processes as a tweaked
out
> version of XML.

> To pass back the recordset to the ASP page do something like this:

> DEFINE CLASS myClass AS SESSION OLEPUBLIC

> Function GetRecordset()
>         local loRS, loConn

>         loRS = CreateObject("ADODB.Recordset")
>         loConn = CreateObject("ADODB.Connection")

>         loConn.Open(myConnectionStringInformation)
>         loRS.CursorType = 1
>         loRS.LockType = 4
>         loRS.ActiveConnection = loConn
>         loRS = loConn.Execute("SELECT Something FROM SomeTable")
>         loRS.ActiveConnection = Null
>         loConn.Close()

>         Return loRS

>     EndFunc
> ENDDEFINE

> You just have to make sure ADO is installed on your application server and
> your webserver (if they are different). The ASP page would look something
> like this:
> <%
> Dim obj, rs
> Set obj = Server.CreateObject("myDLL.myClass")
> Set rs = myClass.GetRecordset()
> Set obj = Nothing

> Do While NOT rs.EOF
>     Response.Write(rs("myfield"))
>     rs.MoveNext
> Loop
> Set rs = Nothing
> %>

> Have Fun!
> -B



Sat, 22 Feb 2003 15:24:17 GMT  
 SCATTERing to an object from an ADO Recordset
I would recommend putting COM objects in your middle tier for the simple
reason that managing a large ASP application is *very* hard and error prone.
I will always suggest putting a complete programming language behind your
website over a scripting language for larger sites. With VFP you get OOP to
boot. We have done some performance testing on a low end Win2k web server
(128K RAM/ 500Mhz/IDE Drive) and an even more pitiful database server. We
were testing heavy data entry and querying (saving and reading) to a
SQL-server database. The VFP components were running in Component Services
(Win2k version of MTS) and could easily handle 100+ concurrent users with
500,000 hits/day (no errors and CPU cruising at about 50%).  This is running
ADO 2.5 and VFP with hotfix to SP4 that you can get from MS.  (There are
issues running VFP SP4 under Win2k.) Depending on your estimated users and
traffic, you should be able to start with the App server and Web server
being the same machine and the DB server another. Adding more servers won't
make the application faster, it will allow it scale to a larger user base.
How many users/hits are you looking at?

-B


Quote:
> Hi, thanks Beth. Last question please, would you know which performs
better
> under
> specific conditions:

> 1) SQL 7 database on a separate server from web server with ASP files
> accessing
> data directly

> or

> 2)SQL 7 database on a separater server, VFP COM objects on a 2nd server,
and
> web
> server on a 3rd one with ASP files accessing data via VFP and passed thru
> with
> the solution you recommended.

> Thank you very much, I'll buy you coffee next time we meet. You're the
> greatest!



> > You can disconnect the recordset from the server and then pass the
entire
> > recordset back to the ASP page. ADO marshals itself better than an
object
> > you create anyways. ADO transports itself across processes as a tweaked
> out
> > version of XML.

> > To pass back the recordset to the ASP page do something like this:

> > DEFINE CLASS myClass AS SESSION OLEPUBLIC

> > Function GetRecordset()
> >         local loRS, loConn

> >         loRS = CreateObject("ADODB.Recordset")
> >         loConn = CreateObject("ADODB.Connection")

> >         loConn.Open(myConnectionStringInformation)
> >         loRS.CursorType = 1
> >         loRS.LockType = 4
> >         loRS.ActiveConnection = loConn
> >         loRS = loConn.Execute("SELECT Something FROM SomeTable")
> >         loRS.ActiveConnection = Null
> >         loConn.Close()

> >         Return loRS

> >     EndFunc
> > ENDDEFINE

> > You just have to make sure ADO is installed on your application server
and
> > your webserver (if they are different). The ASP page would look
something
> > like this:
> > <%
> > Dim obj, rs
> > Set obj = Server.CreateObject("myDLL.myClass")
> > Set rs = myClass.GetRecordset()
> > Set obj = Nothing

> > Do While NOT rs.EOF
> >     Response.Write(rs("myfield"))
> >     rs.MoveNext
> > Loop
> > Set rs = Nothing
> > %>

> > Have Fun!
> > -B



Sun, 23 Feb 2003 11:36:42 GMT  
 SCATTERing to an object from an ADO Recordset

Hi again,

Hmm it's a payroll application that would see peaks during paydates... the
number
of small/medium enterprises targetted is about 40,000, so let's say a very,
very low
signup rate of 1/2 percent would be 200 accounts. Data entry would be for
about
40 employees per account on a payday.

You're absolutely right, I should stick to VFP for the logic, so I'll just
have to review
the diff codes you have on ur site.

Were you able to try a server farm with the VFP COM middle tier running in
parallel
across multiple servers?

Thanks.

Jerry


Quote:
> I would recommend putting COM objects in your middle tier for the simple
> reason that managing a large ASP application is *very* hard and error
prone.
> I will always suggest putting a complete programming language behind your
> website over a scripting language for larger sites. With VFP you get OOP
to
> boot. We have done some performance testing on a low end Win2k web server
> (128K RAM/ 500Mhz/IDE Drive) and an even more pitiful database server. We
> were testing heavy data entry and querying (saving and reading) to a
> SQL-server database. The VFP components were running in Component Services
> (Win2k version of MTS) and could easily handle 100+ concurrent users with
> 500,000 hits/day (no errors and CPU cruising at about 50%).  This is
running
> ADO 2.5 and VFP with hotfix to SP4 that you can get from MS.  (There are
> issues running VFP SP4 under Win2k.) Depending on your estimated users and
> traffic, you should be able to start with the App server and Web server
> being the same machine and the DB server another. Adding more servers
won't
> make the application faster, it will allow it scale to a larger user base.
> How many users/hits are you looking at?

> -B



Mon, 24 Feb 2003 09:49:17 GMT  
 SCATTERing to an object from an ADO Recordset
Ya that sounds like some fairly high numbers. We have not done any testing
in a server farm scenario as of yet, but we will fairly soon. We are
starting off one of our clients with 4 servers (3 web/app servers, 1 DB
server) and we'll se how it goes. They plan on getting at least 2 million
hits per week.

-B


Quote:

> Hi again,

> Hmm it's a payroll application that would see peaks during paydates... the
> number
> of small/medium enterprises targetted is about 40,000, so let's say a
very,
> very low
> signup rate of 1/2 percent would be 200 accounts. Data entry would be for
> about
> 40 employees per account on a payday.

> You're absolutely right, I should stick to VFP for the logic, so I'll just
> have to review
> the diff codes you have on ur site.

> Were you able to try a server farm with the VFP COM middle tier running in
> parallel
> across multiple servers?

> Thanks.

> Jerry



> > I would recommend putting COM objects in your middle tier for the simple
> > reason that managing a large ASP application is *very* hard and error
> prone.
> > I will always suggest putting a complete programming language behind
your
> > website over a scripting language for larger sites. With VFP you get OOP
> to
> > boot. We have done some performance testing on a low end Win2k web
server
> > (128K RAM/ 500Mhz/IDE Drive) and an even more pitiful database server.
We
> > were testing heavy data entry and querying (saving and reading) to a
> > SQL-server database. The VFP components were running in Component
Services
> > (Win2k version of MTS) and could easily handle 100+ concurrent users
with
> > 500,000 hits/day (no errors and CPU cruising at about 50%).  This is
> running
> > ADO 2.5 and VFP with hotfix to SP4 that you can get from MS.  (There are
> > issues running VFP SP4 under Win2k.) Depending on your estimated users
and
> > traffic, you should be able to start with the App server and Web server
> > being the same machine and the DB server another. Adding more servers
> won't
> > make the application faster, it will allow it scale to a larger user
base.
> > How many users/hits are you looking at?

> > -B



Mon, 24 Feb 2003 12:04:54 GMT  
 SCATTERing to an object from an ADO Recordset
hi again.

hmm, being a newbiew to SQL 7, I miss the SEEK and SET RELATION
functionality that the fox provides, especially for calculation intensive
computations that has to sift thru many tables and old records in a tight
loop.

in my payroll application, i do this every payday:

LOOP1 : EMPLOYEE MASTERFILE

    GET EMPLOYEE ID

    SELECT ATTENDANCE FILE

    LOOP2 : ATTENDANCE FILE

        SUMMARIZE DAYS WORKED, OVERTIME OF CURRENT PAY PERIOD

    END OF LOOP2

    DO A MILLION COMPUTATIONS BASED ON ATTENDANCE

    SELECT PAYFILE

    COMPUTE MONTH-TO-DATE INCOME/DEDUCTIONS FROM PREVIOUS PAYFILE RECORDS

    SEEK CURRENT PAYFILE RECORD

    REPLACE VALUES OF PAYFILE RECORD

    NEXT EMPLOYEE

END OF LOOP1

It's so natural doing this in VFP, shifting to different work areas;
is it safe to presume that SQL does the same internally, through
some sophisticated algorithm even though we simply execute
a simple UPDATE command?

Hmmm, I'm wondering if I should stick to the VFP backend?

Thanks.



Thu, 27 Feb 2003 11:26:19 GMT  
 SCATTERing to an object from an ADO Recordset
Hi.  This is not part of your thread, but a question.  The start of this
thread is dataed 10/4/00.  That's what my Outlook Express says.

Is it just me?  How is that possible?



Thu, 27 Feb 2003 11:43:51 GMT  
 SCATTERing to an object from an ADO Recordset
You can set your computer's date to anything, of course.

--

Nancy

Please post replies to the newsgroup
so everybody benefits from the
discussion.

Best viewed with a non-proportional font.


Quote:
> Hi.  This is not part of your thread, but a question.  The start of this
> thread is dataed 10/4/00.  That's what my Outlook Express says.

> Is it just me?  How is that possible?



Thu, 27 Feb 2003 12:04:52 GMT  
 SCATTERing to an object from an ADO Recordset
Yep, it was my fault. I didn't notice that my PC had
the wrong date until the message was posted.

I guess the newsgroup software doesn't use the server
date, but the poster's date as saved on the post.

=)

Again, sorry folks!

Jerry



Thu, 27 Feb 2003 15:49:02 GMT  
 SCATTERing to an object from an ADO Recordset
Hi Jerry
As a guesstimate I bet the number of code lines to do that job with SQL
commands instead of Xbase commands drop to a quarter, whether in VFP with
VFP data or with VFP and a SQL backend.
-Anders


Quote:
> hi again.

> hmm, being a newbiew to SQL 7, I miss the SEEK and SET RELATION
> functionality that the fox provides, especially for calculation intensive
> computations that has to sift thru many tables and old records in a tight
> loop.

> in my payroll application, i do this every payday:

> LOOP1 : EMPLOYEE MASTERFILE

>     GET EMPLOYEE ID

>     SELECT ATTENDANCE FILE

>     LOOP2 : ATTENDANCE FILE

>         SUMMARIZE DAYS WORKED, OVERTIME OF CURRENT PAY PERIOD

>     END OF LOOP2

>     DO A MILLION COMPUTATIONS BASED ON ATTENDANCE

>     SELECT PAYFILE

>     COMPUTE MONTH-TO-DATE INCOME/DEDUCTIONS FROM PREVIOUS PAYFILE RECORDS

>     SEEK CURRENT PAYFILE RECORD

>     REPLACE VALUES OF PAYFILE RECORD

>     NEXT EMPLOYEE

> END OF LOOP1

> It's so natural doing this in VFP, shifting to different work areas;
> is it safe to presume that SQL does the same internally, through
> some sophisticated algorithm even though we simply execute
> a simple UPDATE command?

> Hmmm, I'm wondering if I should stick to the VFP backend?

> Thanks.



Thu, 27 Feb 2003 16:16:52 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. ADO RecordSet Object Closed

2. passing ADO recordset object to DECLAREd .DLL

3. Memory leak with VFP and ADO disconnected recordsets

4. ado and recordset

5. Q: ADO Recordset/SQL query problem

6. Missing records in ADO Recordset

7. create cursor from ADO recordset

8. Convert ADO RecordSet to VFP cursor

9. ADO Recordset update error using Java

10. ADO RecordSet Status Problem???

11. Help with ADO RecordSet -> Foxpro Cursor

12. Using both ADO recordsets and ODBC views in Visual Foxpro 6

 

 
Powered by phpBB® Forum Software