I'm glad that it was helpful. I'd be surprised if learning (or even mentioning) Access would aid in career development once you know SQL Server. It's very different things. SQL Server is a high paying, enterprise class skill. Access is an end user / secretarial skill that exists only for people who don't have the skills to use other products. So by the very nature of it, one is a high paying career, and the other is an essentially unskilled item. So since you are already in the highly paid and skilled workground with loads of experience, going back to an extremely basic "fall back" skill for people who can't do what you do, is likely a waste of time. Anyone that wants Access, but is considering hiring you, would likely just skip the Access project and do it right instead since they'd have you.

@@samit8178 actually, you can use access as kind kind of a GUI to SQL Server, so end users who don't know SQL server can still use the data. You do the heavy lifting with SQL server and the end user will write basic scripts/use drag and drop in access. That's what we do and it works well, people use access and excel to interact with the SQL server back end. Access is nice as a GUI to bigger databases, but it's not the best.if you use it on its own unless your project is small. In that sense it can aid your career, if you want to make users be able.to interact with your database but they may not have experience and need an easy interface.

@@samit8178 I know this is an old conversation, but you are wrong. Yes, Access has some user-friendly built-in functions, however with VBA and SQL skills, you can make very advanced functions in Access, and create applications that compete with the big expensive software solutions.

@@simonmaersk No, no amount of VBA makes Access anything approaching an enterprise application. That's simply untrue. Nothing that runs VB or VBA at all, nothing that requires Access as an application... can even think of being classified as a business tool. Can Access access a real database, sure. Is it ever in any way a proper business tool? Heck no, it's always a total joke. It doesn't meet even the most minimal requirements for something to be considered business class. It has totally unnecessary vendor lock in, huge deployment costs, massive performance issues, an architecture that is an utter joke (client server) and has no place in the current era or for the past several decades. Just because some other crap is "expensive" and bad, too, does not imply that Access can be okay. Anything you can do in Access can be done vastly cheaper, faster, safer, and more flexible using countless actual professional tools (that are free.) There's no benefit to Access, only caveats. Loads and loads or completely unprofessional downsides, zero value.

@@simonmaersk none of that suggests that I am wrong. That you CAN make something bad work doesn't suggest it is good. And yes, some big expensive software is crap. None of that suggests that you should intentionally use bad tools or that you can excuse doing a bad job yourself. Access cannot make software efficiently, cannot produce software that meets any modicum of modern minimal design standards, or can be deployed in any professional way. That it is not alone in being bad and not a requirement for making bad software is very different from it being unable to be good. Access has no place, absolutely none, in software development. There's no way to use it well, and even less way to deploy it.

Thanks! That "serious" picture was me being goofy one day in my apartment.

Glad it helped!

I'm so glad that it was useful! Thanks for the feedback!

Very helpful...Thanks

Yes, it was really to the point and succinct.

Glad that it helped!

Very glad that it has been helpful!

Glad to help!

Glad it was helpful!

Glad it was helpful!

You're welcome

Thank you!

Ten year ago Access was a big more common. I consult heavily in the SMB and while everyone "buys a copy" because it comes free with O365 subscriptions, I actually never run into anyone using it. The cost of deploying Access apps can be very high as you have to license Access for every user of it, and they have to run on Windows (or in some cases, macOS) it can be a bit limiting today as lots of companies use other things, too (ChromeOS, Ubuntu, Fedora, etc.) Calling Access a "database program" is tricky. People use the term database pretty loosely. Access itself is neither a database nor a database program, it's a front end dev tool in the MS Office suite. It uses databases, but so does Excel, and Excel is obviously used 10,000% (real number) more than Access. So just within MS Office, Access isn't the leading database anything. Access is used in the SMB, and that's really the only place. Once you have a company of any size, Access is too limiting, and other options are too common. In an SMB, accessing traditional development resources can be very difficult. But in the enterprise, whipping up the same kind of stuff that Access can do is just as fast or faster for developers to do in code. And then you get more options, flexibility, growth potential. To combat this, MS created the ability to use Access to build web apps that are then hosted on Sharepoint. This forces you out of Access completely, but you still use it to create the apps. But the apps are converted to C# with web forms, hosted on Sharepoint, and connect exclusively to MS SQL Server. But I've not seen that be super popular as it is still expensive and rather complex.

@@samit8178 were can I contact you,have few questions

So yes, SQL Server offers a lot of knobs and dials for people to mess with. But it is important to remember that the defaults are still exceptionally robust. If you are an SMB, you can just install and use it as it is. And just by switching to MS SQL Server over JetDB (the Access native DB) you get benefits in performance, standardization, scalability, and reliability. Plus almost all backup tools can automatically work with SQL Server to take reliable backups, whereas with JetDB, you have a bit of risk in backups unless you kick everyone out while backing up. SQL Server actually has a lot more development options than Access does. Access itself is a dev tool that is meant to be used with SQL Server, using it with JetDB is really intended just for the developer himself to do and to switch to SQL Server for production use (keep in mind that SQL Server Express is free, and can be run on Linux for free, too, so there is zero hint of a required cost involved.) But if you want to move beyond Access, which isn't strictly necessary, SQL Server is a "sky's the limit" kind of tool. Whether you look at other "build apps for me" tools that are "Access-like", or go to a full development stack is up to you (Access is pretty good, not many direct competitors exist.) Most people when looking beyond Access move into full development using a language like PHP or C# and simple talk to MS SQL Server. This approach is the "next step" because it moves to you essentially unlimited power and flexibility. And even lets you break Access' lock in to JetDB or MS SQL Server and lets you choose other RDBMS tools like MariaDB, PostgreSQL, Sybase, or even move to NoSQL options like MongoDB, REDIS, Casandra, and so forth. But the leap is pretty big. So two steps... Access + JetDB -> Access + MS SQL Server -> Full Language + Any Database You Want The biggest advantages of moving beyond MS SQL Server is that many are free and can scale to truly epic levels. So many companies save literally millions on deployments by making that transition.

Awesome.

You're welcome. Glad that it was helpful!

Glad you liked it

Glad you enjoyed it! Thanks!

Either way would work just fine. If you have no other need for Access, that would seem like an unnecessary, extra step. Straight from Excel to any relational database is pretty easy with a trivial script to generate the SQL from the spreadsheet file.

Thanks!

Glad it was helpful!

SQL Server will work great for that. JetDB will be acceptable. I wouldn't say that JetDB is "the way to go", but it would work.

MacOS is a desktop only platform, database management systems are meant to be on servers. So you won't find too much about MacOS + good databases. That said, several enterprise database options like MariaDB, MySQL, and PostgreSQL will run on MacOS just fine. But it would have to be an extreme case where you would do this. Even in an absolutely tiny office with just two or three people, I'd put my database on a server, even a tiny one, and run some flavour of Linux. You don't want any "desktop" product with database in the name in any business situation, not even a two person show. Under business situations, it is the app that talks to the database, never the database, that would run on a Mac. And all **modern** business apps are going to be web based and they won't care if you are on a Mac or not. But it is always the app, not the database, that needs compatibility with your desktops. But if you have desktop limitations from an app, you've got architectural problems with the app itself.

You're welcome

Yes, that's a good idea. Most of the time if you see dataloss in something like that, it is caused by using the shared access file database (AccessDB / JetDB) rather than SQL Server behind the scenes.

So... yeah, about that, lol. This is one of those moments where Microsoft obviously knows better, but they think that all of this stuff is "too hard" for end users to know the truth, so they intentionally use incorrect terms with the intent of making it "easy". And, for someone who doesn't even know what a database is, it does. But to someone who does know what a database is, it is insanely confusing when they use the term incorrectly. They do the same stuff with Hyper-V, they actually have no term for the physical machine, but call one of the virtual machines the physical machine... how confusing is that?

VB is a full featured language. It can use any database that you want.

PostgreSQL and MariaDB should be your first points of investigation for a green field project requiring relational data.

JetDB is what is known as a "database engine", sometimes just called a "database", but technically a database is the set of data read by the database engine. In the open source world, JetDB is mostly closely comparable to SQLite. If you look at MySQL, an RDBMS, it uses database engines under the hood. So for example, one of the database engines of MySQL is InnoDB. One of the database engines of MongoDB is WiredTiger. An RDBMS is a management layer on top of a database engine. You always have to have a database engine, that's what touches the data file. But the DBMS is optional.

The purpose of Access is to avoid SQL. SQL Server uses T- SQL. JetDB the default sometimes called AccessDB used Jet SQL. They are both SQL languages but not identical.

okie dokie

So you say I'm all wrong, yet you never provide any clarity other than "bragging" that you worked with this technology for 20 years. Is there something in the video actually incorrect that you'd like to point out? Do you have something constructive to add? I can only assume that the info is actually correct given the lack of contrary information. And yes, I've worked with Access for more than 20 years, but I also work with lots of other things and understand how it compares.