Francisco Tapia
my.lists at verizon.net
Tue Feb 4 23:00:36 CST 2003
:O, said to hell with mySQL :O that itself is a shock. I'm intrested in the mySQL layer but have not had the opportunity to even look at it let alone even read an ounce of decent documentation.. :( I figured that by this time this year, I'd be exploring the avenues of the wininet.dll or something somesuch that would allow my apps to perform a Symantec'esq Live Update...but oh well, deadlines will be deadlines and derailed projects are doomed to never be finished :( -Francisco http://rcm.netfirms.com/ ----- Original Message ----- From: "Arthur Fuller" <artful at rogers.com> To: <dba-SQLServer at databaseadvisors.com> Sent: Tuesday, February 04, 2003 5:33 PM Subject: RE: [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 :