William Hindman
wdhindman at dejpolsystems.com
Sat Jun 24 16:15:41 CDT 2006
...sorry about that null post :( ...here are some UNOFFICIAL answers that are from about as good an Access source as there is ...inserted below with ##### identifier ...I did not add any comments because this list discourages intemperate language :( ----- Original Message ----- From: "William Hindman" <wdhindman at dejpolsystems.com> To: "Access Developers discussion and problem solving" <accessd at databaseadvisors.com> Sent: Sunday, June 18, 2006 11:13 AM Subject: Re: [AccessD] DAO,VBA,A2K7? > ...ok ...here's an abbreviated version of a list that Allen Brown > maintains > plus some of my own gripes: > > Long standing bugs: > > 1) using Close method gives no warning if record cannot be saved > ...requires > workaround to ensure data integrity. #####1) Not fixed in VBA. However, macros have error handling now, and you may find that you can work around the problem that way. #####2)As you know developers need to try to commit the record before calling close. We modified our button wizard and made sure that all the close buttons in our templates do the right thing. I recommend developers copy and paste a template close button to get the right behavior. > > 2) Name Auto-Correct causes more problems than it addresses and is a > performance hog ...at a MINIMUM the default should be off. #####1)You can now create a template database to be used whenever you create a new (blank) database. If your template has the Name AutoCorrect properties turned off, then every new database you create will also. To create the template, create a new database named blank.accdb in: \Program Files\Microsoft Office\Templates\1033\Access Set these properties, and others (e.g. turning of Datasheet Schema changes.) Set your standard references. Include your template form and report. Include your table of standard ribbon code xml, and so on. You can also set up a blank.mdb in the same folder if you are using A2007 to create files in the old format. #####2) We have fixed a TON of name autocorrect bugs. All of our localized databases are created using name autocorrect which has helped stabalize the feature dramatically. We don't agree that name autocorrect should be turned off for non-developer apps. There are many cases in our templates where end users instanciate a template and rename tables (issues --> bugs) that are really important scenarios. Using autocorrect in our template development has made the feature dramatically more stable as it now has the worlds greatest check-in test running on it every build. > > 3) DAO not upgraded to reflect improvements in Jet engine and ADO > ...record > level locking being an example ...I actually have to open a rs as ADO, set > record level locking, and THEN change it to Dao in order to use this > functionality native to Jet4. #####1) The DAO reference now refers to 2 different libraries: - dao360.dll in an mdb (as currently used) - acedao.dll in an accdb I would not expect the old one has been upgraded. JET 4 functionality that was not exposed in DAO 3.6 is generally not there in acedao either, AFAICT. #####2) we didn't do anything specific here. > > 4) the bookmark bug has resurfaced in every version in one form or > another; > A2K3 required a hotfix to prevent writing the wrong record to SQL dbs. #####1)Not tested. #####2) Fixed in 12 and later SPs. > > 5) data displayed incorrectly, i.e.: form detail section blank if no > records > to display and no new records can be added ...which is bad enough but then > controls in the form header or footer ARE visible but the data in them is > wrong. #####1) Not tested, but I don't expect to see any change here. #####2) The form being blank is by design. The controls in the header and footer should be shown for backwards compat as theere are scenarios where the user might be expecting to use them (such as a search criteria). I haven't seen scenrios where the data is wrong. Please submit a bug if you can repro scenarios where data displayed is wrong. > 6) decimal fields sort incorrectly ...and when do we get a decimal data > type > in VBA? #####1) Not fixed. (And my guess is that we won't see many resources going into extending VBA either.) #####2) Looking at Allen's repro this is fixed in 12--I didn't repro it with my post beta 2 build. http://allenbrowne.com/bug-08.html. We likely won't see a true decimal in VBA. > > 7) record level locking in Dao w/attached tables makes some transactions > fail ...just love the consistency. #####1 Where I have personally seen this bug is with JET 4 front ends connected to an Access 97 back end. Of course, JET 3.5 did not have record-level-locking, so JET 4 should have just ignored the setting, but instead the transactions failed until the setting was turned off. I have not experienced this bug when using a JET 4 back end, so perhaps this bug becomes less relevant with each new version. #####2) Don't use 97 backends if you are using record locking. > 8) Allow Zero Length table property defaults to Yes ...are they begging > for > trouble? #####1) Not fixed. You still have to programmatically set this for all fields in your database. #####2) We will look into changing the default. All of our templates have already turned off Allow Zero Length. > 9) Subdatsheets default to Auto for Christ's sake! #####1) Not fixed. You still have to programmatically set this for all tables in your database. #####2) This is one of those urban myths. We had a developer look at the queries. When a table is opened, the relationships are retrieved for that table. We don't pull down any data from related tables until the user actually clicks on the plus sign. The query to figure out the relationship is quite small and fast. For remote databases we do retrieve the relationships but that is rather small. Of course, you can set the property to explicitly to avoid the relationships check. If folks have a good repro we would love to look at it. > 10) Allow Design Changes defaults to True ...can they spell corruption! #####1)Not sure if you are talking about: a) AllowDesignChanges property of the form, or b) AllowDatasheetSchema property of the Database. The form property is not changed, but is irrelevant in an accdb, and not even exposed in the Properties pane. Instead we have things like AllowLayoutView to consider. The new AllowDatasheetSchema property is probably even more important, since you don't want users renaming or inserting fields in your tables. Fortunately, all these settings can be addressed by creating a template blank database (#2 above.) #####2) We think layout mode is very helpful for users creating new databases. When you are ready to deploy your database there is a new master database property that changes the setting for the database. This should be exactly what folks want. > 11) select queries miss records i.e.: an outer join involving a literal > value in the join field behaves as an inner join in Access ...that's just > one example ...try querying linked SQL Server tables ...or not. #####1) Not fixed. #####2) We are looking into it--thanks for the great repro Allen... Now that we own jet we might be able to fix these types of issues. It might be a little late in the cycle to take a risky fix like this--also, changing queries to return different results is always a bit scary as people come to expect behavior. > 12) queries yield the wrong results when comparing anything to Null using > the inequality operator. #####1) Not fixed. #####2) We are looking into it--thanks for the great repro Allen... Now that we own jet we might be able to fix these types of issues. It might be a little late in the cycle to take a risky fix like this--also, changing queries to return different results is always a bit scary as people come to expect behavior. > 13) the DISTINCT predicate is inconsistent in eval of nulls depending on > how > the field is indexed. #####1) Not fixed. #####2) We are looking into it--thanks for the great repro Allen... Now that we own jet we might be able to fix these types of issues. It might be a little late in the cycle to take a risky fix like this--also, changing queries to return different results is always a bit scary as people come to expect behavior. > 14) DATES! ...how could they have not fixed the way access handles dates > ...user types in a wrong format and Access GUESSES at what they meant > ...often incorrectly ...and the numbnuts user is given no warning ...not > to > mention the problems with how it handles international dates ...or > doesn't. #####1) Not changed AFAIK. #####2) Date fields in our field template, table templates and out of the box templates have a validation prohibiting Dates that are greater than 1900. There is even more we could do here in the future. > 15) Currency format is not retained when Regional Options are changed > ...and > works differently than the help file says. #####1) Behavior not changed. I understand this in in fact by design. (Have not checked the help file, which won't be complete yet.) #####2) This is by design. Please provide a link to the help topic and we should be able to update it. > 16) no way to spec the data type for a calculated field which causes > innumerable problems and workarounds. #####1) I don't believe this has been fixed, with the exception that you can now specify data types for the columns when importing from Excel. #####2) You can by wrapping calcs with CDbl(), CInt(), etc. That is the Jet equivalant of casing data types. > 17) RecordCount is deadly unless you use MoveFirst/MoveLast first. ...why > is > this not native? #####1) This behavior might not be what you expect, but I believe it it > reasonable. > The alternative would be completely unacceptable performance. > In my view, this is a trap to be aware of, not a bug to be fixed. #####2) Yep. By design. It is all about perf. > > 18) MoveNext without checking for EOF first can error ...why does this > still > exist? #####1) Again, this is a trap, not a bug, in my view. A developer who issues the instruction to move to the next record when there are no records is issuing a bad instruction. #####2) By design. Otherwise developers would end up in infinate loops all over and be complaining about how Access does stupid stuff. > 19) the HELP file ...the @#$%^&*(!@# NO HELP files!!! ...the design team > for > the Access >97 help files should expect to spend a long, long time in > purgatory ...does the Access development team realize just how many of us > working in 2000, 2002, and 2003 feel compelled to retain and use the A97 > Help file because the subsequent ones were, imnsho, written by people who > learned English as a Second Language and know zip about indexing? In point > of fact, if word spread that the A2K7 Help file actually works, that alone > would be sufficient motivation or me to upgrade. #####1) Help/documentation is always the last phrase of a project, whether it's your own database you are developing, or the Office dev team. There is no point writing it until everything else has settled down, so a beta always has incomplete help. Surely the final help will be better in both content and functionality. The best new aspect is the exposed reference number on any help item. If you are an educator or consultant, it will be really useful to a student/client/newsgroup poster a reference to specific help. ####2) As (*****) says, help is always the last thing. There have been significant more resoruces dedicated this time than previous versions. The team will continue to improve articles based on feedback and hit counts. There are some really nice archictectural improvements that should help significantly. In a recent MVP meeting after a full presentation on help the group thought we fixed all their core archictural problems (Offline help, links to specific topics, search across developer and end user content, full text search, improvements to developer topics generation, etc). About a year after 2007 ships, you should find help looking far better than in the past. > ...the REALLY aggravating thing is that all of the above are long-standing > problems through several versions and require me to address them in every > Access mdb I build ...and the A2K7 team wants to sell me a fancier gui and > SharePoint integration instead ...like I said, they need a hard boot in > the > crotch as a reality check. > > William > > ----- Original Message ----- > From: "Martin Reid" <mwp.reid at qub.ac.uk> > To: "Access Developers discussion and problem solving" > <accessd at databaseadvisors.com> > Sent: Sunday, June 18, 2006 6:36 AM > Subject: Re: [AccessD] DAO,VBA,A2K7? > > > William > > I posted this questin to them a lot of weeks ago. > > Could you provide me with a list of the bugs that have been fixed in this > release. Not new features BUGS FIXED. > > I am waiting for a reply. > > If you would like to frame up the question for me I will pass it on to > them. > > Martin > > Martin WP Reid > Training and Assessment Unit > Riddle Hall > Belfast > > tel: 02890 974477 > > > ________________________________ > > From: accessd-bounces at databaseadvisors.com on behalf of William Hindman > Sent: Sat 17/06/2006 23:53 > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] DAO,VBA,A2K7? > > > > ...did they get the single record locking in Dao recordsets fixed in > beta2? > > ...can't believe we get a new Access dedicated Jet engine and 99% of the > changes go into the gui and hyping SharePoint services ...who the heck > wanted SharePoint integration as their #1 priority? ...how about spending > their time integrating ADO and DAO with the best features of each? ...if > the > Windows types no longer control the Access engine, the Access team should > stop trying to make it into a client/server fe ...that's VB.Net's niche > ...or should be. > > ...at least it looks like the image bloating issue has been fixed at long > last (what did it take, ten years?) ...but I'm not moving clients to A2K7 > just for that, a fancier gui, and SharePoint. > > ...someone needs to kick the MS Access team where it hurts ...if this is > all > the meat in A2K7 I'm going to be putting a lot more time into SSE be's for > A2K3 fe's for the foreseeable future and keeping an eye out for a viable > Linux replacement down the road. :( > > William > > ----- Original Message ----- > From: "Martin Reid" <mwp.reid at qub.ac.uk> > To: "Access Developers discussion and problem solving" > <accessd at databaseadvisors.com> > Sent: Saturday, June 17, 2006 3:31 PM > Subject: Re: [AccessD] DAO,VBA,A2K7? > > > At the moment William I would say no. DAO has some changes but mostly to > do > with the new SharePoint related types, Attachment and Allow Multiple > Values. > > I am actually working with both DAO and ADO in 2007 and for all the day to > day type stuff there would appear to be little changed at the moment. > > If you want to send me a sample I can test it out for you in terms of > speed > etc in A2003 and A2007. > > > > Martin > > Martin WP Reid > Training and Assessment Unit > Riddle Hall > Belfast > > tel: 02890 974477 > > > ________________________________ > > From: accessd-bounces at databaseadvisors.com on behalf of William Hindman > Sent: Sat 17/06/2006 20:23 > To: Access Developers discussion and problem solving > Subject: [AccessD] DAO,VBA,A2K7? > > > > ...those of you working with A2007 > > ...has there been any upgrade to DAO? ...the idea that in A2K3 I have to > connect via ADO, set single record locking, and then change to DAO just to > get that fundamental feature in DAO recordsets drives me nuts ...as does > the > idea that ADO performance is so abysmal compared to DAO in local table > lookups and many other areas as to be unacceptable ...has any of this > changed with the new jetdb format in A2K7? > > ...any notable changes to VBA in A2K7 that would make the upgrade from > A2K3 > worth the cost and effort? > > William > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > <http://www.databaseadvisors.com/> > <http://www.databaseadvisors.com/> > > > > > > -------------------------------------------------------------------------------- > > >> -- >> AccessD mailing list >> AccessD at databaseadvisors.com >> http://databaseadvisors.com/mailman/listinfo/accessd >> Website: http://www.databaseadvisors.com >> <http://www.databaseadvisors.com/> >> > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com > <http://www.databaseadvisors.com/> > > > > > > -------------------------------------------------------------------------------- > > >> -- >> AccessD mailing list >> AccessD at databaseadvisors.com >> http://databaseadvisors.com/mailman/listinfo/accessd >> Website: http://www.databaseadvisors.com >> > > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com >