I don't usually, but... 10037

Dave.J Eggleston

But I have, and it rarely lets me down.

Is that all you can do? No wonder you think so little of Access' capabilities - you have none yourself. I, on the other hand, make it sing arias with useful programs such as:

* a program to import and validate email addresses, auto-generate Outlook emails and auto-attach documents to them. Simple but effective. This one saved the client mucho money versus the old manual method of navigate-find-attachment-cut-n-paste-hit-Send * a web spider that uses the MS InternetTransferLib object * a system to generate and parse XML queries and responses, using the MSXML libraries * a system used by a corporate legal department to produce charts and graphs re: cases and lawyers and billable hours * a system to manage the life-cycle process of new franchises, from license agreement to opening day * a restaurant decor specifications management system * a food & beverage survey system * a project-based time and billing system * an airfare generator - start with contract data provided by carriers, apply tariff rules, taxes, zones, markups, competing fares scraped by the above XML system, etc, and spit out sets of fares posted later to the client web site. Orbitz is using that one right now. * an airline inventory program * a system to manage contract labor, billing rates, project buttignments * various membership systems * various survey systems * a golf scoring and analysis system * etc etc etc

Those are common issues seen with inexperienced Access users. What else did you want: a regurgitation of the MS Knowledge Base?

As for your sarcasm about my skills, put up or shut up. Propose a smallish system and we'll both submit DDL-designs to cola and let the DFS-haters judge.

I agree 100% that Access isn't a true client-server model. I never represent it as such, and I don't deploy it as such, and depending on the system size I actually recommend against it. I did last Friday, matter of fact, proffering Oracle as the superior solution (even if Oracle is slight overkill for the system).

It just depends, doesn't it? On who's paying the bill. On what resources they have in place. On the size of the system.

btw, ever hear of discretion? That's where you don't give yourself away as a cheap rube of an OSS devotee who claims SQL Server license costs are huge.

I really have been using Access for a decade, and I really do write my own VB-VBA (notice the caps. Is it the most popular programming language, or the 2nd most popular?).

But why would you think I need to write wrapper functions to process Jet transactions? I write DAO and ADO code. Probably a million lines of it by now - and that's no exaggeration.

The 'db.Execute (SQL), dbFailOnError' statement is my very best friend.

I don't get you. It's not a hack; it's a methodology for deploying multi-user Access systems.

You MS-hating, anti-Access wackos are a curious bunch. You think your experiences and incompetence with Access is universal. It's not.

In 10 years I've deployed probably 60 paid systems that used Access databases (maybe 35 as the sole datasource), and I've lost only a handful of records - 10 or 20 if I'm being generous. I've certainly seen corrupt databases that needed repairing from time to time - maybe 5 of them. In 10 years. Across several dozen systems.

Splitting the front- and back-end is just the way it's done.

If you knew Access, you'd know it's a file-server system, and backups are as simple as compress and copy to a backup medium.

When I do write importexport routines I use TransferText or open the file in code and read-write the contents line by line.

You're obtuse. And very insulting considering the frailty of your "knowledge."

What's your problem?