[dba-SQLServer] stored procedure R/O

Yes much better in A2002. Most notably support in design and run for UDFs.
Although MS-specific and non-portable, UDFs are a reason to love MS-SQL,
IMO. The more I learn about them the more I love them, and to hell with
their unportability to Oracle and MySQL and DB/2!

-----Original Message-----
From: dba-SQLServer-owner at databaseadvisors.com
[mailto:dba-SQLServer-owner at databaseadvisors.com] On Behalf Of Francisco H
Tapia
Sent: July 11, 2002 3:40 PM
To: dba-SQLServer at databaseadvisors.com
Subject: RE: [dba-SQLServer] stored procedure R/O

nope nothing wrong with it if you are only making a single trip to the
server...as for ADP's yes the documentation is very poor, AFAIK ADP
technology is much better in A2002, but I haven't tried it...

-Francisco

-----Original Message-----
From: "Bojan Knezovic" <bojan.k at sezampro.yu>
To: <dba-SQLServer at databaseadvisors.com>
Date: Tue, 9 Jul 2002 09:00:40 +0200
Subject: RE: [dba-SQLServer] stored procedure R/O


Thanks for the tip, but the problem in the first place was that I
created ADO recordset from sproc and assigned it to the form. This
produced data that couldn't be updated. I have come around this using
the InputParams field of the form (real neat, you set the data source of
the form to the sproc and then in this field you can set the values for
all the parameters). This produced a form with updatable data that takes
care of itself, without ever having to issue UPDATEs, create views,
write code or whatever. And technically it is loaded from a sproc so
from that point of view it is OK. I don't know if there're some problems
with this approach, documentation on ADP's seems to be very poor.

Bojan

> -----Original Message-----
> From: dba-SQLServer-owner at databaseadvisors.com 
> [mailto:dba-SQLServer-owner at databaseadvisors.com] On Behalf 
> Of Francisco H Tapia
> Sent: Tuesday, July 09, 2002 6:57 AM
> To: dba-SQLServer at databaseadvisors.com
> Subject: Re: [dba-SQLServer] stored procedure R/O
> 
> 
> I don't know why you're doing this.. it seems clear that if 
> the form is
> loaded from a sproc, that you should be able to issue an 
> update by picking
> up the modified field from your form.... a trick you can use 
> is load all
> your controls is to cycle through your textboxes and your 
> fields to find the
> matching names (minues the prefix of txt) and load each 
> control as needed,
> you can have the afterupdate of each control affect the tag 
> value of each
> control so you can use it as a compare basis against the 
> stored data... then
> just pass those values back to your stored procedure that handles the
> update....why call the data and filter it again???  You've 
> taken a 3 trips
> to accomplish 1.
> 
> -Francisco
> ----- Original Message -----
> From: "Bojan Knezovic" <bojan.k at sezampro.yu>
> To: <dba-SQLServer at databaseadvisors.com>
> Sent: Monday, July 08, 2002 12:00 PM
> Subject: RE: [dba-SQLServer] stored procedure R/O
> 
> 
> > Oh, never mind this... I found the "problem". I forgot the 
> form was R/W
> > and issuing an UPDATE on the new connection was as if some 
> other user
> > modified the record. Technically, UPDATE was not necessary at all.
> >
> > This is all still new to me so these kinds of "problems" are not
> > unexpected. :)
> >
> > But I'm curious what was your solution? What do you use?
> >
> >
> > > -----Original Message-----
> > > From: dba-SQLServer-owner at databaseadvisors.com
> > > [mailto:dba-SQLServer-owner at databaseadvisors.com] On Behalf
> > > Of Mike and Doris Manning
> > > Sent: Monday, July 08, 2002 8:41 PM
> > > To: dba-SQLServer at databaseadvisors.com
> > > Subject: RE: [dba-SQLServer] stored procedure R/O
> > >
> > >
> > > Include your code... I think I have a solution for you 
> but need to see
> > > your code to be sure...
> > >
> > > Doris Manning
> > > Database Administrator
> > > Hargrove Inc.
> > > www.hargroveinc.com
> > >
> > >
> > > -----Original Message-----
> > > From: dba-SQLServer-owner at databaseadvisors.com
> > > [mailto:dba-SQLServer-owner at databaseadvisors.com] On 
> Behalf Of Bojan
> > > Knezovic
> > > Sent: Monday, July 08, 2002 02:30 PM
> > > To: dba-SQLServer at databaseadvisors.com
> > > Subject: RE: [dba-SQLServer] stored procedure R/O
> > >
> > >
> > >
> > > Very well, I think I'll stick with the ADP.
> > >
> > > Now, one more question. :) I have a R/O form that gets the
> > > record from a
> > > stored procedure (one row only). When I want to edit this 
> data, I open
> > > another form that uses a view as it's data source and I
> > > filter it out so
> > > that it shows only one record again. I change something, click the
> > > button that issues the UPDATE, open the first form and close
> > > the second
> > > one. After this I get some error about the lock conflict. Any
> > > ideas why?
> > >
> > > I will include code if needed.
> > >
> > >
> > > Bojan
> > >
> >
> 
>