@Uncle Gizmo is our most AI conversant expert and he is working with several. Perhaps he will chime in and suggest which of the AI's he uses has the best actual knowledge of Access and VBA.
Well, I wouldn’t go that far!!!
I find working with AI as exhilarating as when I first conquered MS Access and became conversant with its fantastic abilities. I get the same thrill now, working with large language models. The learning curve is much the same—you learn by making mistakes—and I’ve learnt a lot!!!
The biggest mistake you can make with a large language model is believing what it tells you. My first educational experience came about when I answered a question on the Access World Forum about MS Access VBA. The LLM had supplied me with Microsoft Excel VBA! That’s when I realized that large language models don’t really have a clue. The solution is down to you—it’s how you ask the question.
I specify in my question something along these lines as a prompt:
DRAFT
You are an expert in Microsoft Access VBA. You must be aware that there are different flavours of VBA. The VBA for Microsoft Office differs across programs: for instance, you cannot use some parts of Excel VBA in Access and vice versa, the same applies to Word and other Microsoft programs. When you return a code solution, ensure that it comes from a Microsoft Access-based source. Some large language models can search the internet, and if you are using one of those, instruct them to check against the Microsoft examples on the Microsoft website.
As you can see, that’s a terrible prompt—I just wrote it off the cuff for this post. But here’s a tip for you:
You’re using a large language model to help you, so feed your DRAFT prompt attempt back to the large language model, and it will give you a polished prompt.
The following is a rough draft of a prompt I want to give to a large language model to help me get an expert answer to a Microsoft Access question. Please could you spell-check and punctuate it, and adjust the wording to suit. <<<
Prompt Returned:
You are an expert in Microsoft Access VBA. Only provide code and solutions that are valid specifically for Microsoft Access, not Excel, Word, or other Office applications. If code differs between Office programs, always choose the Access version. When possible, cross-check your answer with official Microsoft documentation to ensure accuracy.
The large language model, ever helpful, also suggested a shorter version:
System instruction (strict):
“Respond only with solutions valid for Microsoft Access VBA; reject or ignore any code that applies to Excel, Word, or other VBA environments.”
Now, the next thing you should bear in mind is that if it can’t find an answer in the official documentation, it will resort to forums, GitHub, and other internet resources. These resources allow people to discuss their issues and suggest solutions—but who’s suggesting the solution? Is it coming from a top MS Access developer? You can’t know for sure. Unless you have a pretty good idea about MS Access, you could wind up using a really crappy idea.
This is why you have to use large language models frequently—constantly—to suss them out. And even then, I still get caught out!!! I’ve wasted hours, sometimes a whole day, chasing my tail through something I thought was a good solution provided by the model, only to discover it wasn’t.
However, the more you use a large language model, the more experience you’ll have in spotting when it’s hallucinating or “swinging the lead.” Sometimes I think it even takes the piss… and I’m not joking around. Some of the forums where it gets this knowledge are manned by some very unsavoury people, and the large language models pick up on this. I know this for a fact, because I had a good chat with a model to the point where I practically broke its conditioning and got it to answer sensibly. I blogged about it somewhere else…
