Wanna say something? Go right ahead and say it. I'm listening.

Thanks, Tony. You are the first commenter on this blog and I really appreciate it. I lean toward Grok for some tasks, mostly image manipulation. However, I long ago settled on Claude Code. It's hard to make a change at this point. I look forward to seeing what you are doing. Is it available somewhere?

Hi George, Good to have the comment thread going on the blog. I have been watching your Access-to-PowerApps work. I am puzzled, because I thought you were using Blazor. I may have that wrong. I tried Blazor first myself and ran into all sorts of problems. Your hybrid idea looks like the one that stuck: Access on the desktop, PowerApps in the browser, SQL Server behind both. I didn't think PowerApps had the legs, but it appears you have found its legs and given it wheels as well! I have been on the same problem from a different angle. I used Grok Build to turn Microsoft sample databases, and some of Gina Whipp’s table-only models, into web pages. They are at https://niftyaccess.com/ --- each run, each conversion, raises and issue or two... once solved Grok Build updates the agent/skill markdown documents, the more conversions you make the better it gets. Now it is practically automatic! It takes between 10 and 20 minutes for each conversion. That's from the downloaded zip file to an up and running webpage... Mind you I have noticed that Grok Build leaves out tables it doesn't think are required!! --- I might have to have a little chat! I would like to hear how the Northwind PowerApps build is going, and whether the scaffolds are now writing forms as well as tables? Tony Hine https://niftyaccess.com/

Re:- One difference between what you are doing and what I am doing is that you are building on the Access stack and retrofitting. My aim is to duplicate a Microsoft Access database and put it on the web. Research into the nuances of Application.SaveAsText revealed interesting details about its formatting. The method produces a highly condensed, stacked text representation. SaveAsText has been part of Microsoft Access since its early versions (at least Access 2.0 in the mid-1990s). It was originally designed to serialise Access objects such as forms, reports, macros and queries from pre-canned sources (for example, the wizards shipped with Access). Because storage was at a premium in those days, the format omits any property that is still at its default value; no placeholder or label is written for omitted items. Grok Build was able to interpret this sparse format. Combining the SaveAsText output with the Python COM interface to Access allowed it to extract table designs, table contents and form definitions, then reproduce them as a working web application. You might rightly ask: why copy from an existing Microsoft Access database when a large language model could simply create the web application from instructions, with no intermediate step? I am creating a service in which a customer sends their Microsoft Access database. Drawing on experience processing more than twenty such databases, recording every nuance, resolving problems and storing the resulting knowledge in agent/skill Markdown files, there is a realistic chance of achieving reliable conversion. However, most real-world databases are not constructed to modern standards. They are frequently years out of date and have been modified by successive authors, each adding their own idiosyncratic touches. Rather than reverse-engineering and converting a customer’s often messy, multi-author Access database, the better path is:- 1. Identify the closest clean, industry-standard Access template from the library here:- https://niftyaccess.com 2. Assemble additional patterns drawn from other well-structured samples. 3. Overlay the customer’s specific requirements. 4. Use the resulting clean Access database as the single source of truth from which Grok Build generates the web version. This approach produces a database that follows current industry practices. The customer therefore receives both a modern, well-structured Microsoft Access database and a matching web application generated from that clean template.

Your builds reflect a similar concept to what I'm aiming for with Open Template Standards. If I understand correctly, and there's no guarantee of that, the main difference is that your method starts with an accdb object and has AI extract objects from it to build the output, where OTS starts with a scaffold and has the AI build new objects from a description of the desired outputs. Theoretically, it seems to me, the objects generated can, and will, vary structurally each time. I say that because the LLMs we use are probabilistic, not deterministic. Even if you start from a known quantity, i.e. one of the Microsoft Access templates, you can't guarantee identical builds. What are your thoughts on that?

Re:- George observed:- Even if you start from a known quantity, i.e. one of the Microsoft Access templates, you can't guarantee identical builds. ---- UG Replied I am no longer using Blazor... I am putting these examples directly on the web, See:- [niftyaccess.com](https://niftyaccess.com/demo/lookup-combo/).--- this is my latest example which I am showing because the VBA is sophisticated, you can see it here... [niftyaccess.com](https://niftyaccess.com/blog/one-lookup-table/) at the top of the page you can download the Microsoft Access zip file:- Download the Access file (Access 2007+, fictional Role A seed -- not a diocese file). LookupCombo.zip The technique outlined below enabled GROK BUILD (GB) to turn the LookupCombo.zip MS Access database into a web hosted database see here:- [niftyaccess.com](https://niftyaccess.com/demo/lookup-combo/). The secret is to use skill.md and agent.md markdown documents, every time you discover a tendancey for the LLM to drift you note it in a skill.md and/or agent.md... The next trick is to use deterministic Python Script wherever possible... these cannot hallucinate! And the final stage, the LLM and again, with a set of deterministic Python Scripts vets the completed project for drift and hallucination. The source of truth is the Microsoft Access Template, so now your deterministic Python Script has a solid unbreakable pattern to follow and check everything against Deterministic Python is the source-of-truth adapter The Access file is the source of truth, but the LLM cannot read it reliably. Python can. Minimum extract (unbreakable pattern): Schema — tables, columns, types, sizes, required, defaults, validation rules, captions, descriptions Keys & relationships — PK, FK, join type, cascade, enforced RI Indexes — unique, ignore-nulls, primary Queries — SQL text, parameters, type (select/action), row source usage Forms/reports — name, record source, controls (name, type, control source, row source, event hooks present or not) VBA surface — module names, procedure names, event procedure signatures, referenced objects (not a full semantic compile on day one) Macros / data macros — name, embedded vs standalone, table they attach to Seed / sample data fingerprint — row counts, checksums of business keys, not necessarily every blob

Nifty Access Date Picker This webpage is the direct conversion of my nifty date picker:- https://niftyaccess.com/demo/date-picker/ You can also download the original MS Access database which contains the date picker, it's on that webpage! The web copy perfectly emulates the original MS Access database, and to be honest the web version is much better looking, even looks better than Isladogs (Colin's) perfect date picker, which I have always been jealous of!!! The conversion usually takes between 10 and 20 minutes... I can't begin to tell you, how exhilarating it is to watch GROK Build churn out all these web pages! 10 minutes for small ones 20 minutes for bigger ones sometimes more.. 20 odd examples created with very little effort on my part, I'm just supervising... I set it off, I go out and water the plants, do some chores! Come back check the build, authorise the upload to the web. Job done!