However, I am serious. My main resolution is to post more often on databaselessons.com.

I will start with a serious of postings about queries.

If you have been at the MS Access game for a while, you may find most of these query postings too simple. Well, this site is for people that are just shedding the pure wizard approach to MS Access, and so you may be right.

As always, please leave comments if you have a good one.

Thanks for reading.

Richard “Manxman” Killey

A new offering is Kexi, which is a Free/Libre and Open-Source integrated data management application. Kexi is a long awaited Open Source competitor for products like Microsoft Access. Kexi can be used for creating database schemas, inserting data, performing queries, and processing data. Forms can be created to provide a custom interface to your data. All database objects – tables, queries and forms – are stored in the relational database, making it easy to share data and design.

Unfortunately, although Python and Ruby programming languages are supported (beta stage) and JavaScript support is in development, scripting is not yet available on the Windows version.

I do not think I could live without VBA. It makes Access what it is for me. Here is a link to the scripting info for Kexi.

For now, I have to sit in the wings, until the scripting is ported to the Windows version of Kexi.

No, I am not going to take the easy way out with an excuse.

Anyhow. Received 2 comments. One via the website and one via email. I appreciate both comments, even though they both were against me (at least a little!). The website comment was in regards to this posting about php and mysql. If you visit the posting you can read the comment.

My response? What can I say? I let my subscribers down. I will do my best to write another in the series, but not until after my daughter’s wedding. (hmmm, not good enough; only gives me 9 days grace!)

The email was about primary keys.

Hi Richard

Good to hear from you (been a while since you’ve uploaded a new article), and hopefully everything has been going well with you.

Just wanted to mention that your statement “Every table must have its own primary key” is a little misleading from our experience over the years. Lookup tables do not always need a primary key, whereby master tables should be since they’re the ones being ‘queried’ on a repetitive basis. The problem with Lookup tables just ordinarily being given a primary key is when the data is not meant to be ‘in order’. For example, a list of Job Titles in a single field table. Over the years a couple of clients have jumped on us for listing them alphabetically (naturally happens with a Primary Key on that field), when they should be listed in a hierarchical manner, e.g. CEO, CIO, President, 2nd VP, etc.

Just thought we’d add our two cents.

Keep up the good work,

My response?

I appreciate your comments.

Life always has exceptions, but I’ll stand by my preference this time.

Actually, if you read the fine print, I ALWAYS use autonumber fields for primary keys. I never want user generated data as a primary key. Some would consider me picky, but that’s okay, because your database is yours and ….

My need for a primary key is to provide for 1-to-many relationships, primarily. Now if you ponder that, why do I have them on the many sided table if it is a “dead end”? The answer to that comes via the style of unbound form that I use so often (which is another personal style some do not like, but, that’s okay cause …)

As to your example … in the hierarchical manner, e.g. CEO, CIO, President, 2nd VP, etc, what solution did you come up with, or have thought about, to allow simple sorting?

Dialogue is great, even when the other party disagrees, or tells you off!

Now I want to write more on both topics, and get some more dialogue going.

This is fun, even when it hurts!

What was the offending activeX control? A calendar. If you have not already done so, see my series about a calendar control that is pure Access (no activeX) starting at this web page.

if a = b then
   do something that does NOT affect a or b
   do something else that does NOT affect a or b
   if a = b then
      do a lot of stuff
   endif
endif

Why are there 2 identical if statements, with no code inbetween that affects the comparison test?

This reminds me of the article I wrote, called Working with Other Developers. Please spend at least a little bit of time on the “look-and-feel” of your VBA code. It makes it much easier for someone else (maybe even you) to read and understand your logic.

p.s. another problem with the system I am working on is that it has a lot of orphaned code. That is, code that is no longer attached to an object, and will never run. Some of this code causes the Access compiler to choke and sputter, and I depend on the compiler to help me find errors. Hence, I had to spend time getting rid of the orphaned stuff.