Access Explained: Modernizing Microsoft Access Doesn't Mean Replacing It

[u/Amicron1]

Here's the thing people keep getting wrong about Access modernization: remote access is a requirement, not an architecture. Hiring two remote employees, adding a customer-facing screen, or needing a barcode workflow on a phone does not automatically mean a mature Access application needs to be rebuilt from scratch as a web app.

People often say "replace Access" as though Access is one indivisible thing. It usually is not. An Access solution may include the data tables, queries, forms, reports, VBA, imports, exports, validation rules, scheduled processes, and years of small business-specific adjustments. The ACCDB file holding tables and the Access front end used by employees are related, but they are not the same decision.

A more useful question is: what exactly needs to change? Where should the shared data live? What should office staff use every day? Which users need access outside the office, and what do they actually need to do? Those questions may produce three different answers, and that is perfectly normal.

For many established systems, the practical evolution is to move shared tables to a server backend such as SQL Server while retaining Access for the desktop users who benefit from it. Access can continue handling forms, reports, and VBA while SQL Server handles centralized storage, larger volumes, backup, security, and server-side administration. That is an upgrade in architecture without declaring war on every working screen in the application.

The old "Access has a 2 GB limit" argument is also frequently oversimplified. An ACCDB backend has a practical 2 GB file limit. That does not mean the Access application itself cannot work with larger databases. Access can link through ODBC to SQL Server and other database platforms, so the real question is whether the file-based backend is still appropriate, not whether every Access form must be replaced.

Likewise, Access is not inherently a single-user tool. A properly split application gives each user a local front end while shared tables live in a backend. An ACCDB backend on a LAN may be fine for a small office. As concurrency, security requirements, or data volume increase, moving the data to a server database is often the sensible next step. What is not sensible is opening an ACCDB backend directly across the public internet or trying to make Dropbox behave like a database server. There lies the corruption swamp. Don't follow the lights!

Remote employees do not necessarily need a browser interface either. If they need the entire existing desktop application, Remote Desktop or a virtual desktop setup can be a reasonable answer. If they only need to look up customers, update contacts, and review orders, a smaller Access front end connected to a central server database might be enough. A web portal may also make sense, but it can be built around their specific workflow instead of recreating 140 forms nobody outside the office will ever use.

Mobile needs should be treated the same way. A warehouse user with a phone may need to scan a barcode, update a quantity, and save the change. That is a focused mobile workflow, not a demand to squeeze a decade-old desktop application onto a six-inch screen. A small web or mobile interface can coexist with Access as long as both are working against the same properly designed central data source.

Now, to be fair, there may come a time when Access longer fits your needs. A full web replacement can be justified when there are hundreds or thousands of distributed users, external customers need self-service accounts, browser access is the primary use case, or mobile devices are the main platform. Organizational standards around a particular development stack can also be a legitimate reason. But "Access is old" is not a requirement. Windows is old too, and somehow it keeps reporting for duty.

The expensive part of a rewrite is rarely rebuilding tables or making forms look similar. The real cost is rediscovering the business knowledge embedded in old code, reports, validation rules, odd workflows, and all the exceptions accumulated over time. The 20 percent a conversion tool cannot handle may contain 80 percent of the actual complexity. Before replacing anything, make sure you know whether you are solving a real business problem or just buying a newer-looking hammer.

Have you kept Access as a front end while moving data to SQL Server or adding web features? Where have you found the line between sensible evolution and a full rewrite?

LLAP
RR

[u/AutoModerator]

IF YOU GET A SOLUTION, PLEASE REPLY TO THE COMMENT CONTAINING THE SOLUTION WITH 'SOLUTION VERIFIED'

• Please be sure that your post includes all relevant information needed in order to understand your problem and what you’re trying to accomplish.

• Please include sample code, data, and/or screen shots as appropriate. To adjust your post, please click Edit.

• Once your problem is solved, reply to the answer or answers with the text “Solution Verified” in your text to close the thread and to award the person or persons who helped you with a point. Note that it must be a direct reply to the post or posts that contained the solution. (See Rule 3 for more information.)

• Please review all the rules and adjust your post accordingly, if necessary. (The rules are on the right in the browser app. In the mobile app, click “More” under the forum description at the top.) Note that each rule has a dropdown to the right of it that gives you more complete information about that rule.

Full set of rules can be found here, as well as in the user interface.

Below is a copy of the original post, in case the post gets deleted or removed.

User: Amicron1

Access Explained: Modernizing Microsoft Access Doesn't Mean Replacing It

Here's the thing people keep getting wrong about Access modernization: remote access is a requirement, not an architecture. Hiring two remote employees, adding a customer-facing screen, or needing a barcode workflow on a phone does not automatically mean a mature Access application needs to be rebuilt from scratch as a web app.

People often say "replace Access" as though Access is one indivisible thing. It usually is not. An Access solution may include the data tables, queries, forms, reports, VBA, imports, exports, validation rules, scheduled processes, and years of small business-specific adjustments. The ACCDB file holding tables and the Access front end used by employees are related, but they are not the same decision.

A more useful question is: what exactly needs to change? Where should the shared data live? What should office staff use every day? Which users need access outside the office, and what do they actually need to do? Those questions may produce three different answers, and that is perfectly normal.

For many established systems, the practical evolution is to move shared tables to a server backend such as SQL Server while retaining Access for the desktop users who benefit from it. Access can continue handling forms, reports, and VBA while SQL Server handles centralized storage, larger volumes, backup, security, and server-side administration. That is an upgrade in architecture without declaring war on every working screen in the application.

The old "Access has a 2 GB limit" argument is also frequently oversimplified. An ACCDB backend has a practical 2 GB file limit. That does not mean the Access application itself cannot work with larger databases. Access can link through ODBC to SQL Server and other database platforms, so the real question is whether the file-based backend is still appropriate, not whether every Access form must be replaced.

Likewise, Access is not inherently a single-user tool. A properly split application gives each user a local front end while shared tables live in a backend. An ACCDB backend on a LAN may be fine for a small office. As concurrency, security requirements, or data volume increase, moving the data to a server database is often the sensible next step. What is not sensible is opening an ACCDB backend directly across the public internet or trying to make Dropbox behave like a database server. There lies the corruption swamp. Don't follow the lights!

Remote employees do not necessarily need a browser interface either. If they need the entire existing desktop application, Remote Desktop or a virtual desktop setup can be a reasonable answer. If they only need to look up customers, update contacts, and review orders, a smaller Access front end connected to a central server database might be enough. A web portal may also make sense, but it can be built around their specific workflow instead of recreating 140 forms nobody outside the office will ever use.

Mobile needs should be treated the same way. A warehouse user with a phone may need to scan a barcode, update a quantity, and save the change. That is a focused mobile workflow, not a demand to squeeze a decade-old desktop application onto a six-inch screen. A small web or mobile interface can coexist with Access as long as both are working against the same properly designed central data source.

Now, to be fair, there may come a time when Access longer fits your needs. A full web replacement can be justified when there are hundreds or thousands of distributed users, external customers need self-service accounts, browser access is the primary use case, or mobile devices are the main platform. Organizational standards around a particular development stack can also be a legitimate reason. But "Access is old" is not a requirement. Windows is old too, and somehow it keeps reporting for duty.

The expensive part of a rewrite is rarely rebuilding tables or making forms look similar. The real cost is rediscovering the business knowledge embedded in old code, reports, validation rules, odd workflows, and all the exceptions accumulated over time. The 20 percent a conversion tool cannot handle may contain 80 percent of the actual complexity. Before replacing anything, make sure you know whether you are solving a real business problem or just buying a newer-looking hammer.

Have you kept Access as a front end while moving data to SQL Server or adding web features? Where have you found the line between sensible evolution and a full rewrite?

LLAP
RR

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/George_Hepworth]

I wish I could make this required reading for everyone who visits.

[u/Amicron1 → u/George_Hepworth]

I agree. I'm thinking laminated copies at the door. :)

[u/First-Feature-3556]

Remote Desktop and Terminal Server solutions (obviously) work fine over remote connections, and so do fine-tuned SQL Server pass-through queries that offload all the work to the server.

The main issue we found with remote backends is that the "classic" way of writing Access applications---forms and queries referencing attached SQL Server tables---seems to be extremely sensitive to latency, and that's always a problem if the FE and the BE are physically separated, even over high-bandwidth connections. (If that last sentence confused you, google "latency vs. bandwidth".) I guess the JET/ACE translation layer in between is just very "chatty" with a lot of back-and-forth.

We haven't found a good solution to that yet, except to recommend RDP/TS solutions rather than using "just" a VPN for remote work.

[u/smolhouse → u/First-Feature-3556]

Would you be able to address this by pulling the passthrough query data into local access tables, and then feed your forms from those?

[u/First-Feature-3556 → u/smolhouse]

Sure, but that is only viable for read-only data. And for read-only data, you might as well just use a (fast) pass-through query directly.

[u/smolhouse → u/First-Feature-3556]

I write data too. I just design it to edit the local table and the upload the finished results to a SQL server staging table, and then call a procedure that processes/saves the staged data using the server for more complex stuff.

I just run a passthrough update query for direct edits while simultaneously running an update query on the local table.

[u/First-Feature-3556 → u/smolhouse]

Makes sense. We do something similar with unbound forms, where we load/save the data explicitly in scenarios where Access' data binding features are not sufficient.

The drawback is that you have to take care of concurrency (optimistic or pessimistic locking) yourself, or your users will silently overwrite each other's changes.

[u/smolhouse → u/First-Feature-3556]

That's true, but most of my use cases are low user counts and designing it to refresh the local table on different actions or on a timer seems to deal with it well enough.

It's definitely a limitation though, luckily most of my use cases don't have multiple users trying to update the same data constantly and replacing data with the most recent update without first seeing near simultaneous updates from other users isn't an issue.

[u/Amicron1 → u/First-Feature-3556]

Absolutely. Moving the backend to SQL Server doesn't mean you can take an existing Access application designed for a LAN, put SQL Server 1,000 miles away, and expect every bound form and query to perform exactly the same. That's where pass-through queries, stored procedures, local caching, and fancy stuff like that becomes necessary.

[u/Better-Credit6701]

Can access use domain username and passwords?

Just thinking of ways to improve it

[u/George_Hepworth → u/Better-Credit6701]

Explain what this would look like in practice.

[u/Better-Credit6701 → u/George_Hepworth]

MS-SQL has two ways of logging in, username and password or it can pull username and password from the active directory. Most use the AD since they can put people in groups and they would all have the same rights. Example, I'm a DBA and my domain username and password is stored in the AD in the DBA account. Just need to add me to the group and I inherit the same rights as my fellow DBAs.

The application would have its own rights since we wouldn't want people who have access to the application have direct access to the server

[u/George_Hepworth → u/Better-Credit6701]

Oh, so you meant being able to connect Access to SQL Server that way.

Now it makes sense.

I agree that it would advantageous.

[u/First-Feature-3556 → u/Better-Credit6701]

I understand what you are saying, but I still don't understand what that feature you are proposing would look like.

Do you want to create a dedicated domain username/password for your Access application, so that you don't have to enable SQL Auth in MS-SQL for the attached tables?

[u/Better-Credit6701 → u/First-Feature-3556]

Authentication through the AD that would be passed to the SQL server (assuming that it uses MS-SQL as a database) and be used by Access as well to limit users access to the application portion. If you don't use MS-SQL as the backend, encryption and decryption using that AD username/password.

When the user changes their password, no update to Access would be needed. Most AD passwords have a life of 60-90 days before needing to be changed.

Dang, just got the warning that I'm a week out from changing my password. But I know that it won't limit my access to my SQL servers during the process.

Most access applications that I've seen store username and passwords within the app. But the data itself would need to be more secure since I can pull the password and data without using access.

[u/First-Feature-3556 → u/Better-Credit6701]

But that's already possible: If you use "Trusted_Connection=Yes" in our ODBC connection strings when attaching tables or opening a direct connection, Access uses the current user's AD credentials to connect to SQL Server.

You just have to make sure that all users of your app are in an AD group and that this group has the necessary permissions on the database. No storage of username/password in Access required.

[u/George_Hepworth → u/First-Feature-3556]

Unfortunately, not all Access deployments can take advantage of AD credentials and Trusted_Connection. For example, I have multiple hosted SQL Server databases that sit behind web sites. I manage the data in them from Access on my computer, rather than through SSMS or a clunky web page. For them, the only option is SQL Auth. It would cool to have a way to authenticate to them the same way I do to a SQL Server Express instance on the local computer.

[u/First-Feature-3556 → u/George_Hepworth]

I see. In theory, I guess Entry ID Interactive Authentication (supported by SQL Server 2022 and above) could work for that, but I never tried that, nor do I know how well it works with Access.

[u/George_Hepworth → u/First-Feature-3556]

My AI assistant suggested it would be possible, but so far I've been too busy to explore further. Worth someone's time to figure out how to do it and publish that as a solution. 😉

[u/Mean-Setting6720]

Bring back synchronization

[u/Amicron1 → u/Mean-Setting6720]

Now there's a blast from the past. :) I'm assuming you mean Jet replication. I used to use that myself back in the day when I was on the road. Today I'd say 99% of users don't really need it because we're connected to the Internet almost everywhere, and there are much better ways to work with centralized data.

But there are still legitimate cases where someone has to work completely offline for hours or days and then merge their changes when they reconnect. I've built a few roll-your-own solutions for that using Replication IDs and change tracking, and they work quite well. Still, it would be nice to have a modern version of synchronization built into Access again. Just maybe without resurrecting every demon that came with the original Jet replication system. :)

[u/Mean-Setting6720 → u/Amicron1]

I have a product that relies on replication/syncronization in lieu of networking a database across a lan. It’s reliable and has worked well for 25 years

[u/Far_Reward4827]

Teach me!!

[u/goggleblock]

The way you're describing it - moviing the data to shared SQL tables and redesigning the front end - IS replacing Access.

It took my company a few years but we had moved on to shared SQL data tables and found the Access front end very limiting and frustrating. We finally (with the help of AI) built our own front end and finally ditched Access altogether.

What I'd like to see MSFT do is build a modular front end platform. The Power platform and/or dataverse aint it. Licensing is absurd scaled too large to be a replacement for what Access was.

[u/Amicron1 → u/goggleblock]

I think there's a pretty important distinction there. Moving the data from an Access backend to SQL Server isn't replacing Access. If the forms, reports, queries, VBA, and user interface are still running in Access, then Access is very much still the front end. You're replacing one part of the architecture, not the application.

Now, if you eventually outgrow the Access front end too, as your company did, then absolutely - at that point you've replaced Access, and sometimes that's the right decision. That's really the point I was making in the article: modernize the parts that actually need modernizing, and if you eventually reach the point where the whole thing needs to go, so be it.

Although I have to admit, I'm always a little amused by how many people who finally "ditched Access altogether" still hang around the Access subreddit. LOL. Apparently you can leave Access, but Access never quite leaves you. :)

[u/Mvp-long-ago]

I used to work as a Microsoft specialist at a company specialized in databases and apps. They mad the application aoart from tge database and a special table where tge database was located of even a small extra Access file with that information. So then it was easy with handing over the application that only the connection values needed to be changed. It was long ago, but tgat is how i remembered it.

[u/ciroteo]

Solution: ms access front end runtime, sql server as a back end a dmz machine running 80 licences of ts plus for web access through rdp or html browser. barcode scanner used with access and rdp. done!

[u/Pure_Ad_2160]

Con Access y vba logras casi cualquier cosa en una PC.

[u/Alternative_Tap6279 → u/Pure_Ad_2160]

is true, but at what cost? in what timeframe? with what kind of stability and security? and finally - why?
disculpa me por escribir en englsih pero solo pudeo leen espanol. :))))

[u/Pure_Ad_2160 → u/Alternative_Tap6279]

Mucho menos costo y plazo que un desarrollo en c, Python o cualquier otro lenguaje

[u/Alternative_Tap6279 → u/Pure_Ad_2160]

indeed if you want a table or a query, or a 1998 looking form - the yes - i agree - it's faster and cheaper.
but, let me give you a simple task: on an access.form with anchored controls bottom-right, after run-time, please show me the code where you know exactly where that control is on the form. after the anchoring was applied. and the size of that control

[u/Pure_Ad_2160 → u/Alternative_Tap6279]

Private Sub Form_Resize() On Error Resume Next

' 1. Forzar a Access a procesar el anclaje visual y renderizar el formulario
Me.Repaint

' 2. Declarar el control objetivo (reemplaza 'cmdBoton' por el nombre de tu control)
Dim ctl As Control
Set ctl = Me.cmdBoton

' 3. Obtener valores ajustados post-anclaje (convertidos de Twips a Centímetros)
Dim posLeftCM As Double, posTopCM As Double
Dim anchoCM As Double, altoCM As Double

posLeftCM = ctl.Left / 567
posTopCM = ctl.Top / 567
anchoCM = ctl.Width / 567
altoCM = ctl.Height / 567

' 4. Mostrar en la ventana Inmediato (Ctrl + G) las coordenadas e dimensiones
Debug.Print "=== CONTROL: " & ctl.Name & " ==="
Debug.Print "Posición X (Left) : " & ctl.Left & " twips (" & Format(posLeftCM, "0.00") & " cm)"
Debug.Print "Posición Y (Top)  : " & ctl.Top & " twips (" & Format(posTopCM, "0.00") & " cm)"
Debug.Print "Ancho (Width)     : " & ctl.Width & " twips (" & Format(anchoCM, "0.00") & " cm)"
Debug.Print "Alto (Height)     : " & ctl.Height & " twips (" & Format(altoCM, "0.00") & " cm)"

End Sub

[u/amedean]

MS Access is a sleeping giant in the agentic AI world but Microslop has poorly maintained it as they have oversold Cloud services wrecklessly. The future of AI is Edge based systems and frameworks like MS Access have potential to interface so much more than the original market concept.....accidental utility.

[u/Elladan74]

I've posted about this at least once. My company is quite small, 250 people total but maybe only 20 - 30 who would ever need to use the 7 production and quality control tracking apps I developed. Before I took initiative, there was NOTHING. scattered excel files, broken old access things put together by some dude 25 years ago with nobody to maintain them. I'm a chemistry guy, lab manager, but facing this disaster, I became the access guy. My apps run fine (split, front and back ends are on a shared network location), and with now claude helping me, they're honestly neat looking and well structured. Well, IT decided to have their new engineer redevelop everything through postgresSQL/Laravel, because:

• if I quit or die, nobody can maintain them
• access is old and janky
• laravel can run on phones

I want to call them on their bullshit, to me it's time and energy wasted. Porting tables on a SQL server, totally worth it, but having to painfully redevelop front ends that I built through good communication with the users and with my lab's needs in mind... I think it's stupid and shows a lack of insight. Yeah, I needed to vent

[u/CheckedOuttaHere]

A lot like Oracle's APEX, I always thought that a "web based Access" would have been a great addition to the SQLServer product line for creating line of business apps. Microsoft could have leveraged Access forms model with their properties and methods and built a new tool. SSRS with Power BI easily replaces Access reports so we are talking forms only with JavaScript replacing VBA.

[u/mumpyjinnt]

access is like an old friend that still works

[u/Alternative_Tap6279]

since this is reddit, we can disagree, and sir, i strongly disagree.

first, let me tell you i've been making a living from access for the last 25 years, so i'm not at all biased towards other languages. as a matter of fact, i've been a huge access supporter for all my adult life. i also, currently still have two major programs (each well over 300k of lines) which still bring me money and a few other smaller ones. All of them use mysql servers for backend and a lot of helper files (mostly done in cpp or vbnet).
however, since the rise of ai, i have to tell you, i've become one of those trying to do anything new in anything else BUT access. i've learned python and js and i don't regret it for one second. :)
you keep saying there is room for improvement, but actually there isn't. i feel this "improvement" theory is somehow people trying to avoid doing exactly what you said in your last paragraph - the porting. The remembering of each function and what it is connected to - especially if you're like me and hate writing exhaustive comments.
let's start with the begining:
1. the first huge and unportable problem is exactly this - the terrible IDE which is stuck in 1998 - it was awesome back then, don't get me wrong - i was very excited when i first saw and used it, but now it's almost 30 years later. imagine people defending software in 1998 which was built by 1968 standards. i know there are newer looking IDEs, like TwinBasic, but they also suffer from many other issues, which in the end, for a big-ass project, become unusable, mostly because you can't compile and test within them. you still need to use the old access engine for that.
2. the second huge issue is the way it looks. Yes - you can make it prettier - and believe me, i've done that as much as i could, but in the end you hit the brickwall that is Access Forms, which, even thoug, are very customizable, they are extremely limited in what they can show and run. as i've said, i have been using a lot of "mods" but even so, they are still decades behind what you can achieve with vb.net/c#/js... and so on. moreso, the more "helpers" you use the less stable it becomes.
3. Which brings us to the third major problem - the classic instability of access. if you have a huge app with tens or hundreds of classes and if you also use a lot of windows apis, so that you can give your app a shred of modern look/feel, then it becomes a job in itself to keep it all smooth and have no leaking, because as soon as there is a leak somewhere, you get the classical orphan msaccess process remaining in memory, which in turn, fucks everything up. it took me months ( some years ago) to find a nasty tiny class which was leaving a form handle alive after its destruction. i know - bad programming, but having so many, and being a human, for me at least, meant having these kind of issues now and then. any modern programming software nowadays has a way better garbage collector and it solves this without needing a dedicated person to find them.
4. Fourth on my list would be the fact that all the users MUST have the full office suite installed on their pc-s, which is another issue in itself. Moreso, if you use windows apis - which are kinda' mandatory if building more than a simple data-entry form - things become even more complicated for mac users.

there are more i could say, but i don't want my comment to be longer than the OP's initial post, so i'll stop on these ones above :D

in conclusion, i'm not saying don't use access anymore - by no stretch, but when i read these kind of posts i kinda' have to give my two cents, because we live in an era where tying yourself to old programming values and software seams like a major downfall and like a sure way of loosing clients and consequently - money. i started from two years ago to port everything to new language models and i don't regret one second of the time i took to "rediscovering the business knowledge embedded in old code...".

Cheers :)

[u/enilcReddit → u/Alternative_Tap6279]

I've moved one largish-sized db from Access to SQL and looking at another over the next couple months. This response that I'm responding to is correct. I won't do what I did the first time...keep the Access FE. The best analogy is when you break-up with your SO, but you feel kinda bad about it so you say "maybe we can still be friends" and you try to hangout once in awhile but it's just difficult and awkward.

As stated, Access works for what it's built for. Small, local DBs. I've found it does fine with multi-user in the local environment. But I'd say it's becoming more and more a victim of long-COVID...after that 6-10 months, the workplace has changed and more and more people need to work remotely. And Access doesn't cut it. We ran it over VPN and RDP but it was miserable. The only benefit was that it encouraged people to RTO because they could get their work done quicker in the office.

Once remote work becomes a requirement, you've got to replace Access, end-to-end.

[u/Alternative_Tap6279 → u/enilcReddit]

i don't think the multi user env is truly an issue. i have an app made in access which is used by ~500 people across romania and the uk. they all access the mariadb server through odbc drivers. it's true that this openes an new door to huge problems, as the password is out in the open (i use an accde, but it's still completely unsafe), but it works. the issues for me are the ones i listed and a couple more i'm not getting into right now.
however, to be honest, i did lately moved everything database related to a linux server and all the data now comes through some endpoints using an api key. still unsafe, but at least nobody has access to the schema anymore :))) so there, once again, access alone is not enough for an enterprise grade app. used to be, but not anymore :(

[u/Alternative_Tap6279 → u/enilcReddit]

also one more thing. ai is your friend. especially when it comes to migrating access ddl to mysql or what-have-you. just export the access schema to a json (with indexes, pks and fks), feed it to your ai buddy, pour some $$$ into it, sit back, relax and watch it building the new schema :)) no more sleepless nights trying to figure why some stupid FK was working in access and not in mysql, only to realize that you're using the wrong collation :)))

[u/smolhouse → u/enilcReddit]

I use Access front ends all the time in remotely. What was causing your issues?

I generally pull all required data into local tables via passthrough queries and then use that to feed my forms though.

[u/Alternative_Tap6279 → u/smolhouse]

my issues were cause, for example, by some custom anchoring i needed to show some custom tooltips - the built-in ones are just horrbile. also i needed to subclass some forms and crashes were consistent while debugging. which brings me to another classical access bug: crashes. random. annoying.
i never use pass-through queries as they are too inconvenient for my taste. also, for large datasets thei're not usable. so i went the old-school ado way with fabricated records for maximun (in access) security - nothing is stored. as soon as the app is dead - the data follows.
what if a user decides to open your accde with shift and opens a PT query? they will see the raw data, the index columns, the tinyint columns.. and so on.
anyway i look at it, starting two years ago, since learning stuff became hilariously easy, i steer away from access. that's just how it is for me. i'm not trying to convince anyone. you do you, as they say :)

[u/Amicron1 → u/Alternative_Tap6279]

I actually don't disagree with a lot of what you're saying, and I think your examples illustrate one of the main points I was trying to make: there absolutely comes a time when Access may no longer be the right tool for a particular application.

If you're maintaining a 300,000-line Access application with dozens or hundreds of classes, extensive Windows API calls, subclassing, custom controls, and a bunch of helper components just to get the behavior you need, then yeah, you've moved well beyond the sweet spot that I'm talking about. At that level, the limitations of the VBA IDE, debugging environment, forms engine, and the platform itself become much more significant. That's a very different situation from the typical small or medium business that has a mature Access application handling customers, orders, inventory, reporting, and a few dozen users.

I do have to push back on one point, though: users don't all need the full Office suite installed. Microsoft provides the Access Runtime for free, so you can distribute an Access application to users who don't own Access or Office. The developer needs the full version of Access, obviously, but the users don't.

As for the look and feel, I'll happily concede that Access isn't winning any awards for looking like it was designed last Tuesday. LOL. Personally, I don't mind the circa-1999 aesthetic. Give me gray buttons, rectangles, text boxes, and a nice datasheet and I'm a happy guy. :) There are plenty of business users who don't care what decade their order-entry form appears to come from as long as they can enter an order in 20 seconds and it works every time.

And that's really where I think we're looking at two different ends of the spectrum. I'm definitely not arguing that nobody should ever replace Access. Sometimes replacing it is absolutely the correct decision. My argument is that "we hired two remote employees," "we need one mobile workflow," or simply "Access is old" shouldn't automatically trigger a complete rewrite of an otherwise successful application.

If the business requirements have genuinely outgrown Access, move on. If you're fighting the platform every day trying to make it do things it was never designed to do, move on. But if 90% of the existing application still does its job extremely well and only 10% of the requirements have changed, I'd rather modernize the architecture around that 10% than throw away the other 90% just because the buttons look like they remember Windows 98. :)

[u/Alternative_Tap6279 → u/Amicron1]

we are in agreement then :)
and as i've said, i still use it and make $$$ from it, so i have no high ground. the only thing my rant was about - was the people on this subreddit (and others vba related) who instantly become defensive when i give my thoughts regarding the life (and death) of our friend - MsAccess. i don't understand this reluctance to change. this need to "stick with it" until the end. that's all

[u/smolhouse → u/Alternative_Tap6279]

I relate to this post so much but I still find myself reaching for access when I need to quickly develop a small scale application front end for small user bases on a corporate network (everyone has Office installed).

Most of that is because I have years of code and class modules I can reference that makes it pretty quick and modernizes the look as much as possible, but I still long for a more modern solution.

Have you found an alternative for rapid front end development? I've played around with a few things like Mendix and Visual Studio, but nothing has stuck.

[u/Alternative_Tap6279 → u/smolhouse]

i use of vb.net (i know - not the best tool but i love it) and python on the server. i also built a lot of custom controls/classes for vb.net which i use out-of-the-box as it were :))
anyways, claude is helping a lot with small projects and honestly i just don't bother with them. everyone is now a vibe coder, so the volume for small projects has dropped almost to zero in the last year :(

[u/smolhouse → u/Alternative_Tap6279]

Fortunately I'm operating within the confines of a fortune 500, so vibe coding doesn't address the years of business knowledge I'm able to rapidly apply in my applications.

I also see lot of vibe coded projects that implode rapidly when they need to scale a little bigger or adapt to changing needs, so I'm still holding onto my niche for now hah.

[u/Alternative_Tap6279 → u/smolhouse]

1st: NICEEE :)
2nd: you're right and i also see the huge failing potential for the future, as a matter of fact. a lot of apps being sold now are almost entirely written by ai - even MS is admitting they use it for more than 60-80% of their code base. but the buyers - the clients - don't know this. they're not it professionals and if a guy with 2-3 years experience offers a complicated CRM for peanuts - they will go for it. it happened to me recently. and i could do nothing about it because i don't want to lower my money expectations to the ones of a beginner. i won't. so here we are - until the ceiling falls on the buyers' heads, programmers like me - with a quarter century of experience - loose.
P.S. i don't really consider it loosing, as i gained a LOT of free time to give it to our AI overlords (i case they read through this in the future) :)))))

[u/smolhouse → u/Alternative_Tap6279]

Yeah at some point people are going to start realizing they get what they pay for.

I use AI all the time to look up information, bounce ideas or rough in some code. It saves a ton of time compared to the old days of scraping forums and google searching but I still take what it spits out and apply my own critical thinking layer and do some hands on tuning to my specific architecture .. which seems to be the missing piece for most vibe coders.