main logo
Subject: Re: A little help with VFP -> SPT
Author: Pete Theisen
Posted: 2003/05/31 21:28:00
 
View Entire Thread
New Search


Hi Bill!

Take pity on me, Ed says I'm a dummy :-)

What is SPT? I googled it and there were 497,000 results. I haven't a clue
which one you-all are talking about.

Regards,

Pete

At 11:35 AM 5/31/03 -0500, you wrote:
>ah - I remember this very well!!!
>started with that concept of storing sql pt code in a backend, retrieving
>the record, and evaluating the code at run time.
>worked very well - even on a small 64K pipe back to the sql boxen... been
>what - about 4 years now ???
>
>was looking at a newer concept last month of the meta stored procedures that
>I wanted to generate -
>and wrapping my head around the fact that there aint no fricking stored
>procs in mySql -
>but...
>I took the same concept from ages past and made it 'work' -
>where its a double-banger sql pass through -
>one to get the meta stored proc
>and another one to run it via spt to the back end.
>
>works very well...
>so..
>my 2 yuan says -
>this is a good concept, and I've gotten it deployed in the past....
>
>ain't spt fun?
>mondo regards [Bill]
>=============================[remove the dot bob to reply]
>William Sanders MCSD, MCDBA , Electronic Filing Group. MSDN ISV - VFP/SQL .
>mySql/ Sql / Oracle with VFP - YUP!!
>972.668.2718 / GoTo China and teach C/SaPPdEV on occasion.
>http://www.efgroup.net
>----- Original Message -----
>From: "Bob Lee" <bobl /AT/ wginc D.O.T org>
>To: "ProFox Email List" <profox@leafe.com>
>Sent: Friday, May 30, 2003 8:25 PM
>Subject: Re: A little help with VFP -> SPT
>
>
>> Anthony,
>> I thought sure I was the only one who would have thought of storing code
>in
>> sql server. Really wasnt sure at the time why I did it, but once I
>worked,
>> the idea is more in line with how I feel computers should work
>> Big Ass Dumb database backend, ! Great concept VFP make a nice gui for
>the
>> users, but use a nice solid datasotre in the back room.!
>> Bob Lee
>>
>> ----- Original Message -----
>> From: "Testi, Anthony L (UseTemp)" <anthony.testi-eds /AT/ eds D.O.T com>
>> To: "'ProFox Email List'" <profox@leafe.com>
>> Sent: Friday, May 30, 2003 12:43 PM
>> Subject: RE: A little help with VFP -> SPT
>>
>>
>> > That is one of the core techniques used in my last programming project.
>> We
>> > treated the BackEnds as just big dumb databases. We had one table that
>> > stored our SQLs. There where multiple columns: SQL_NAME, Common, VFP,
>> > MS_QSL, Oracle, mySQL.... Normally only the name and common was filled
>> in.
>> > If the SQL was so complex and had to use specific Language commands such
>> as
>> > IIF for Fox vs. Case for MS SQL we would fill in the other columns.
>> >
>> > Also our framework had built in standard SQLs so that there was no need
>to
>> > add in many records to the SQL table. Commands such as:
>> > Get_Cursor_by_Primary_Key( <Table_Name>, <Primary Key Value>),
>> > Get_Cursor_All_Records( <Table_Name> ), Get_Cursor_by_Field(
><Table_Name>,
>> > <Field_Name>, <Field_Value> ) Etc.
>> >
>> > We dealt with Vars in the SQL statements etc. Worked out well. We could
>> and
>> > did switch different backends on a daily bases.
>> >
>> > Anthony
>> >
>> > -----Original Message-----
>> > From: Bob Lee [mailto:bobl /AT/ wginc D.O.T org]
>> > Sent: Friday, May 30, 2003 9:27 AM
>> > To: ProFox Email List
>> > Subject: Re: A little help with VFP -> SPT
>> >
>> >
>> > so last year, I got to thinking myself about SP's and when they could be
>> > used, and why. What I did was write a few lines of code which allowd me
>to
>> > store a SP - in a table, (say a sp table ) which could keep lib routines
>> for
>> > that database. this way, a user be it PHP programmer, or myself or
>> someone
>> > else could get access to a sql querry - as data, and then send it back
>to
>> > the server with their own var's filled in.. in cocept it went like this.
>> > select myquerry where myquerry_id = "calculate_customer_total" read the
>> > cursor, change the cursor to memvar, eval the memvar to get real data
>into
>> > say the customer account number, pass pack to the server the statment
>> >
>> > Well it worked... not something I was proud of...
>> >
>> > Bob Lee
>> >
>> >
>> > ----- Original Message -----
>> > From: "Ed Leafe" <ed@leafe.com>
>> > To: "ProFox Email List" <profox /AT/ leafe D.O.T com>
>> > Sent: Friday, May 30, 2003 12:18 PM
>> > Subject: Re: A little help with VFP -> SPT
>> >
>> >
>> > > On Friday, May 30, 2003, at 12:03 PM, Stephen Russell wrote:
>> > >
>> > > > SP's to me is CODE that is redundant in nature, asked for too often,
>> > > > and in general deals with many transactions. EOM, EOY, Payroll,
>> > > > Aging Reports for
>> > > > AR, AP. Inventory turn over. You need the WHOLE table for the
>> > > > process,
>> > > > instead of C/S work where I need all customers starting with 'C' for
>a
>> > > > finder list.
>> > > >
>> > > > My POV is to stop bandwidth waste, keep the data on the server for
>> > > > the changes necessary in the process, let the server do what it does
>> > > > REAL GOOD, notify me when it's done.
>> > >
>> > > OK, that makes sense, but there is no need then to pass *any* data to
>> > > the client in these cases. And it doesn't make sense to do this on the
>> > > client, since you'll never have the need for all 50 desktops to be
>> > > running EOM, right? Instead, you only need something on the client to
>> > > trigger the process on the server.
>> > >
>> > > Now whether that process is a SP or something like a Python script on
>> > > the server that does the processing really doesn't matter. In this
>> > > case, I'd write the code in Python, install it on the server, and
>> > > build a way to call the script from my app.
>> > >
>> > > ___/
>> > > /
>> > > __/
>> > > /
>> > > ____/
>> > > Ed Leafe
>> > > http://leafe.com/
>> > > http://opentech.leafe.com
>> > >
>> > >
[excessive quoting removed by server]


 
©2003 Pete Theisen
<-- Prior Message New Search Next Message -->