2010: Essential Diffs?
in [Help]
|
From: Albert D. Kallal on 11 Apr 2010 00:06 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message news:Xns9D56C44F37313f99a49ed1d0c49c5bbb2(a)74.209.136.98... > > All that was ever lacking was procedural code, and that continues to > be the case with table-level data macros. Perhaps I misunderstanding the above or I likely am taking it out of context? The new table macros are procedural code and they can even traverse or loop over records from other tables. So, a trigger in table A can read and loop on records from table B for example. For those data macros you don't use sql to update data. In fact there is no declarative "update" expressions and one has to write procedural macro code to update the data. So, there is things such as "for each record" and there also if/then/else block code structure and the ability to create variables. And, if your database is not split then those table macros can even return values back to a UI macro called from in a form. -- Albert D. Kallal Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Albert D. Kallal on 11 Apr 2010 00:44 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message news:Xns9D56C1D816F91f99a49ed1d0c49c5bbb2(a)74.209.136.98... > > You're also leaving out the new calculated fields (I can't recall > the name), Yes, the above is what we are calling them these days. > which for a single-table calculation obviate any need to > store the value at all (though I would guess it's actually handled > behind the scenes with a hidden table-level data macro), so you'd > just add the calculated field to your table's list of fields and be > done with it, and not even have to set up the trigger. > > Right? Yes, the above is correct. And there is certainly is something that "fires" much like a data trigger. However it is interesting to note that the calculated column is instantly updated any time any other column involved in the expression is modified DURING the editing of data. So you don't have to wait until the record is saved for that column to be usable. This hints that it might not necessary be implemented via the table macro features that ACE has. However the above is sheer speculation and guessing on my my part. I really don't know how it was implemented, but I think it safe to say it sure feels and seems like some kind of trigger. Of course this column can only be a expression as opposed to macro code. However, as noted before, the value is stored as a column and thus there not a performance hit once the expression has been processed. So, no question "something" runs here when data is updated, but it occurs before record update time. So, the advantage of using calculated column is of course it can't be edited and it updates instantly in a form during editing of data. Unfortunately for the life of me I can not understand why calculated columns can't be indexed, but I suspect the issue is the "real time" updating (but even then that makes no sense). For custom invoice numbers or expressions that will be searched and it would be a good design decision to have an index on that column, then you best use a trigger that creates that expression in macro code and then stuffs it into a regular column which of course can be indexed as always. So, for me, no indexing reduces this feature usefulness. I mean, having a full name column that is searchable would be a great use, but without indexing allowed, then I can see me using a trigger in some cases. I really should write and post a soundex routine in macro code. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: David W. Fenton on 11 Apr 2010 16:20 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:gtcwn.89967$y13.30722(a)newsfe12.iad: > I really should write and post a soundex routine in macro code. Exactly the kind of thing I already had on the agenda for moving to table-level macros. If you do it, you should consider implementing it as optionally Soundex (which I find mostly useless on its own) or Soundex2 (which I find much more useful by itself). -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: The Frog on 12 Apr 2010 02:41 Thanks for the detailed answers. There is a relatively large jump it seems between A2003 and A2010. I like the sound of A2010 (I dodged A2007), and especially am finding myself drawn to table level macros. If you do proceed down the path of creating a Table Level Macro (TLM) for something like Soundex(2) would you be so kind as to 'record' your creation like a demo? I would be fascinated to see this TLM capability at work. I am a little concerned at the hesitation surrounding peoples adoption of the 64bit version. I would have thought that there were significant advantages to having the 64bit version, especially when it comes to performance. Native 64bit code runs seemingly much faster than 32bit code on 64bit processors. I can understand that Windows API code would need refactoring, but to be able to take VBA and run it as native 64bit code I thought would have been a real boon. I would imagine even more so for heavy data analytical applications (where most of my time goes these days.....). Am I mistaken in thinking 64bit is a plus here? Or is this just the same adoption scare that took place when shifting from 16bit to 32bit code - or perhaps more of the Win 95/98/Me to 2K 'scare' (OMG - I dont have DOS anymore......whatever will I do.....Oh wait, it actually is there......but I'm still scared.....). I would like to think that moving to 64bit is the way to go, but perhaps I am just wishful thinking. Cheers The Frog
From: Banana on 12 Apr 2010 10:20
The Frog wrote: > I am a little concerned at the hesitation surrounding peoples adoption > of the 64bit version. I would have thought that there were significant > advantages to having the 64bit version, especially when it comes to > performance. Native 64bit code runs seemingly much faster than 32bit > code on 64bit processors. I do not believe this is an accurate assertion to make. A 64-bit program would actually take more memory and require more computation than a 32-bit program so it could be actually slower. It's same thing as how adding 22 + 22 is going to be slower than adding 2 + 2 -- the operation is not any more difficult but there's more stuff to put together so it takes more time & resources. This doesn't mean that 64-bit program can't outperform 32-bit but rather that the benefits of 64-bitness does not kick in until we reach a certain volume of data/processing. An example is how Mac OS X which has long time supported 64-bit (you'd be hard-pressed to find a new 32-bit Mac nowadays) but yet the kernel itself continue to run in 32-bit mode. There's just no need for a non-server Mac to run a 64-bit kernel even though it's available and can be manually coerced. For the same reason, some people may find it convenient to install 32-bit programs on 64-bit Windows so it can continue to be compatible with other 32-bit programs. So I'm inclined to think that 64-bitness really isn't the magic bullet... for end users anyway. There's certainly big benefits in terms of servers but not so much for end users. Mind, this wouldn't change the adoption rate at all - eventually, 32-bit computers will go the way of DOS and green screens whether it's actually needed or not. People don't need color monitors and could do just fine with green screens yet we wouldn't find any green screens in most mainstream uses. I suspect same will be true of 32-bit computers eventually. The 64-bit processors will certainly outperform 32-bit when we have large data to work but really, how many people whom aren't DBAs are actually working with >4 GB of data (or even >1 GB) out there? Very few, if any, I would think. But I don't think we can say more bits = more performance. That's not a fair statement to make because the reality is much more complicated than that. > I can understand that Windows API code would > need refactoring, but to be able to take VBA and run it as native > 64bit code I thought would have been a real boon. I would imagine even > more so for heavy data analytical applications (where most of my time > goes these days.....). Am I mistaken in thinking 64bit is a plus here? I'm not understanding what you are saying here. VBA7 already natively support 64-bit, so it's a done deal. |