Re: Migrating from DBF to SQL
I agree, I would rather them edit the record from a form then the
actual browser. I just was interested in what other people thought. My
application still has a parent /child relationship that might have
child records that are never unique, so i still have to create a column
like "ap_control" to identify the record. I was also interested in what
other people did in this situation.
Ginny Caughey wrote:
> Yes and no. <g> If you have VO2Ado Pro and the Classmate extensions, then
> you can use the cDataBrowser to browse your data and you'll know which
> record in the recordset you're on. But for doing anything fancy from that
> point, I get whatever the unique key would be from the browser current row
> and set a filter to that record to work with it from that point on. In any
> case I've never allowed users to edit from my browsers - they use the
> browsers to find the record they want, then I give them a form specifically
> for editing based on that. So this approach gives me and them the experience
> we all want.
> "Geoff Chambers" <email@example.com> wrote in message
> news:firstname.lastname@example.org ups.com...
> >I also use Classmate and display all of my files in browser based
> > windows. I am not using VO2ADO and access the data using the SQLServer
> > statement. I do all of my editing/adding/deleteing using the sqlselect
> > statement editing it in a dialog box. There is a added level of
> > difficulty, knowing what record to update, since the sql statements
> > have no recordset.
> > I am curious, with VO2ADO, would I still have this problem? Would i be
> > able to edit the data directly in the browser?
> > To eliminate the recordset problem I have actually had to add a column
> > to act as a record no. since their is no real distinct record in a
> > couple of detail tables I have.