View Single Post
  #13 (permalink)  
Old 01-14-2007, 11:01 PM
Geoff Chambers
Guest
 
Posts: n/a
Default 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:
> Geoff,
>
> 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.
>
> --
> Ginny
>
>
> "Geoff Chambers" <gchambers02@msn.com> wrote in message
> news:1168794916.400660.258900@11g2000cwr.googlegro 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.
> >


Reply With Quote