This is trial code that I used to translate an error from a Yahoo web service into a COM ErrObject.
It's not real XML parsing, but good enough for this purpose. IF an error message is sent, we extract the message and then use Err.Raise to throw an error.
I was having a real WTF moment with Access. I'd coded up an SQL query in access, and a string had a single quote in it, fouling up the query.
The SQL was something like this:
This is some code and controls that help you geocode addresses, and prepare a report of addresses sorted by distance from a point.
Here are some Excel macros that help to clean up data. Once cleaned, it's easier to remove duplicates. (I used these to de-dupe a list exported from Outlook.)
This is a subroutine that will scan your Outlook inbox or a subfolder of inbox named "Bounces", and copy bounced email addresses to a MS Access database.
This is the start of a macro that will scan your Outlook Inbox or a subfolder named "Bounces" for bounce messages, and record such messages to an Access database.
Jawahar on Expertsforge says this is an SQL syntax error where a
These are some functions that help you write a script to import Excel data into a SQL database. What makes this different from the Access import feature is that the data can be poorly formatted.
I've been working with "unbound forms" and, ay ay ay, what a pain in the butt. Unbound forms are regular forms, except that the controls aren't associated with any data source. An unbound form is like a panel of controls, without wires behind them, and no information being shown or recorded. It's like a prop without a performance. It's weird to use an Access form that doesn't seem to work, because the data structure behind it doesn't exist -- without information, there's no animation.
Example of how to add a row to a db table, in ADO:
http://msdn.microsoft.com/en-us/library/ms677536(VS.85).aspx
Gripe: VBA syntax is difficult. The object system is a little confusing too. It's just very hard to use. To make things even more difficult, the sample code out there is kind of *weird*. Maybe there's some good reasons for doing things their way, but, it just seems verbose, error prone, and hard to write, to me.
Here's some code that is the start of a library to work with Outlook's folders. It's based on some code samples from the web, refactored into something resembling a library.
The best feature is the function OLGetSubFolder, which returns a MAPI folder object for a given path. Totally useful.