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 DO.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 DO.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 DO.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 DO.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 William Sanders |
|
