Paul Hill <> wrote:
> On 9/6/06, Stephen the Cook <[EMAIL PROTECTED]> wrote:
>> Paul Hill <> wrote:
>>> Hi Peeps,
>>>
>>> I'm connecting to a SQL Server using server side cursors. If I do
>>> the following:
>>>
>>> SELECT * FROM big_table
>>>
>>> Followed by:
>>>
>>> RecordSet.FindFirst("keyfield = 123")
>
> I was getting my DAO and ADO confused here, what I really wanted was
> RecordSet.Seek("123"). This seems to actually work.
>
>> Sounds like you know that this process is wrong, yet you look for
>> approval because your "fixing" it. Sorry but you really need to get
>> the refactoring hat on and map out the proper path for C/S because
>> when you ask for all the rows from a big_table your stuck. :(
>
> As it's a server side cursor not all the data is returned to the
> client. I know it's a hack, but I'm thinking about a 1st step.
>
>> ADO or ADO.NET it's just not built on
>> lots of rows in the object. Never has, and only going to ADO.NET in
>> VS2005 will it work much better even though it still WRONG.
>
> The problem is I'm working on a fairly big project (600+ PRGs) and
> we're not a large company. It's actually the market that is
> demanding SQL support.
>
> The code is full of classic Fox code like this:
>
> SELECT table
> SET ORDER TO xx
> SEEK "1"
> SCAN WHILE status="1"
> ...
> ENDSCAN
>
> OK, that's a lie. Actually it's more like this:
>
> table->(ORDSETFOCUS( "xx" ))
> table->(DBSEEK("1")) //
> status blocked
> DO WHILE table->status == "1"
> table->(DBSKIP())
> ENDDO
>
> OK, it's not Fox, so sue me :-) It's XBase++ (a Clipper compiler)
> but I'm a fox programmer by trade which is why I hang out here.
>
> My idea was to make 'table' an object and implement xbase stubs that
> talk to SQL server. That way it's just a search and replace job.
>
> Obviously the best way would be something like this:
>
> oResults = myExecuteSQL("Select * from table where status='1'") DO
> WHILE !oResults.EOF() ...
> oResults()->MoveNext()
> ENDDO
>
> But this is a pretty trivial example. In reality there are often
> Seeks() within the loop. The original programmer had an odd style
> sometimes (but not necessarily bad).
>
> It would be a hell of a lot of work to re-work it like this.
My point was that your forcing the answer to be wrong without asking Yoda
for a dash of double speak.
Issue at hand:
1) you want to update the database.
2) there is conditional logic for the update.
3) your doing a table scan of some sort to define what needs updates
4) you then send the modified data back.
Are there GUI settings that the update is taking into consideration? User
has to approve payments, or user is selecting customers for a pending
promotion?
If not, then why not geneate the darned update statement and be done with it
on the server side of life? Such as EOM processing and all of these rows
are now status flagged as PriorMonth?
Stephen Russell
DBA / Operations Developer
Memphis TN 38115
901.246-0159
http://spaces.msn.com/members/srussell/
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.12.0/439 - Release Date: 9/6/2006
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
