[Medic]

Ok, I am really frustrated right now, and maybe all for nought! I would like to use DAO (not ADO) to work with existing dbase III files. In one of the forms that I would like to create, I am giving the end user (a Physical Therapist) the opportunitiy to fill out a form, which will later be printed. Depending on his client and the visit type the questions to be answered will vary in content and number. My boss has written this program already in Clipper, and we are just giving it a facelift. In his older program, he "browses" a filtered table to allow for the shrinking or growing of possible entries. A data bound flexgrid will do the trick, except that Microsoft has INTENTIONALLY made it impossible to write data to a dbase file in ADO, and the flexgrid (I think) only uses ADO. I could use a neat repeating control, but it would have to also be bound using (you guessed it) ADO. DAO 3.51 works extremely well for this taks and loads lightning quick (as opposed to the 5 second delay with the flexgrid or datagrid). I can use the flexgrid to VIEW the data, but it does not allow entry. Does anybody have any ideas about how to do this. I heard Microsoft may have added this feature back in newer releases of ADO, but I would like to stick with DAO since I have yet to be thrilled with the performance and overhead of ADO.

[Volte]

Well, for now you can stick with DAO, but when .NET comes out, Microsoft will be killing off DAO and doing only ADO. I personally prefer DAO, ADO is too complicated (i guess 'cause I learned DAO first). So if you plan to make this project a long term thing, you should do it with ADO.

[BillSoo]

I'm no DB expert, but I was under the impression that DAO was specifically designed to work with ACCESS. That's why it is so fast. ADO was more general purpose which is why it works with DBIII (albeit slowly).



"I have a plan so cunning you could put a tail on it and call it a weasel!" - Edmund Blackadder

[dcl3500]

That is not true. DAO is not dead in .Net, just not updated any longer. It will still work just as it always has. Way too many of us still use it to completely abandon it. We should always remember that MS has basically always bent over backwards to support backwards compatiblity. So DAO will not go away anytime real soon.

Don

Time is the best teacher; unfortunately it kills all its students.

[Thinker]

It is true that the top of the line grid controls for both DAO (MSFlexGrid)
and ADO (MSHFlexGrid) are both read-only. It is also a fact that serious
database applications developers would never use a pure grid for updating
anthing more than the simplest of tables. The problems with this method
behind the scenes are so numerous it just isn't worth the hassle. On the
other hand, using a grid can be really nice to display a filtered set of rows
or even as part of an update screen where detail lines need to be added
for a parent record in a one to many entity/table relationship. For ADO,
I can use the MSHFlexGrid for lookup and the plain datagrid if I want to
edit detail records in a grid. I still am probably going to use a ADO
connection with SQL Insert/Update statements (or stored procedures) to
do the real database additions and changes.

There is no doubt that DAO is quickly going by the wayside and even ADO
will be old technology if and when .net comes out. Now is the time to get
up to speed on ADO and leave DAO (except for those few basic areas
where it just makes more sense to use DAO.)

I think therefore I am... sometimes right. [img]images/icons/wink.gif[/img]

[Medic]

The issue is not whether I am up to speed on ADO, the issue is the MS is NOT UP TO PAR on ADO. I CANNOT USE ADO in my app because it simply cannot do what I need it to do, which is write to dbase tables. They are easier to administer, easier to keep track of, and less inclined toward database bloat and many other problems, not to mention the program I am giving a "facelift" uses them. I Started out with ADO, and have used it in other apps, but this is not a candidate for it. I am interested in using a Grid Control and possibly making it "unbound", thus adding what I need to add in code. Any ideas!

[Thinker]

I can't speak about working with dbase tables. If there is an odbc driver
for them then I would still use ADO. If not, then they are so obsolete that
it makes no sense for Microsoft or anyone else to bother trying to make a
new data access technology work with them. Ultimately, it all comes down
to economics.

I think therefore I am... sometimes right. [img]images/icons/wink.gif[/img]