Another massive plus to using Access, aside from it's use as a rapid test bed, is that you can create your own custom VBA functions and use those directly inside your sql string/query. This allows you to extend the existing query functionality in extremely powerful ways. Of course, add this to your own custom forms (and more custom VBA) and you take things to the next level.
As far as I'm concerned Access is great database for the personal applications to which I put it. It's never going to be an Oracle or SQL Server but I don't believe it was meant to be that. I find Access to be very useful, especially with VBA and DAO as well as the various wizards. I'm in for the long-term. Thanks for your challenging question.
@@advantageapplications5712 I like your style. Good to see some more Access content, even VBA. I'm an advanced beginner :>). I've been an Excel user for years, I'm transitioning to Access, it is such a cool db. Keep up the good work mate! I've subscribed.
@charlesbaldo True, but access makes a great client program to sql server. I've not used access as the backend for more than 10 years, but that doesn't mean access as the front end is a problem. In effect you thus use access with sql server or SharePoint as the back end. Hence the issues of scaling number of users becomes sql server's problem and not that of using access as the front end to such databases.
@@Albertkallal I am working at a US corporation now that used Access as a Front End for 20 years. It was used as an Enterprise client. They worked well
This brings back a lot of memories. For years I used to make a lot of different MsAccess databases on a server with like users frontends. Often 20 to 40 users. Even created an automatic update system for the users based on version numbers. Very handy for the constant tweaks they wanted. After a while they became slow and you had to compress every table manually. For that I had to remove every link and connect it all back again. I always found the downside you could not turn the user frontends into an executable. Everyone had to have the whole Office Pro suite. I can't remember anything like Sharepoint already existing. Tried various SQL databases, but it somehow never worked too well. I will be watching how this works out.
Since access 2007 the runtime package been free. That means unlimited copies of your application can be deployed for free and without needing any office license.
Oh yes, I've definitely faced some of those same issues. When the companies I work for adopted Office 365, SharePoint, and the Power Platform, they thought they would be retiring Access. But once I figured out that Access could actually interface with these new technologies, they loved it. We could ease into the "new thing" and reduce user learning curve. Someone once said that Microsoft doesn't advance by evolution but by revolution. I find that to be very accurate. This made it seem less jarring.
@@advantageapplications5712 We were lucky to have a good relational model (and I have a background in database development from my education in the 70's and 80's) on our Access 98-era back-end accounting package, which we purchased for maybe 700 dollars with source code in 1999. We were able to move the back end to MySql, which took a bit of head scratching, but actually wasn't that bad, works flawlessly, totally "clusterable" and "cloud ready". MDE's are actually compiled front ends, and the runtimes are free. At that point, who cares what the front end is coded in? As a small business we don't have to be concerned about having a maintenance contract, so we keep a current version of access licensed for DEV, everything else is free. Frankly, there is very very little that was added in the last 25 years to SQL, every day I'm impressed how complete the VBA/Access environment was back then. If I had chased "modernity" back then, I'd have literally hundreds of thousands of dollars less in my retirement account. And he best thing, is that ODBC and Excel pivot tables are the most incredible reporting engines. So for us, Yes. Totally Viable.
I love Access for learning, for building out simple databases. The firm I worked for, one of the largest in the UK ran most of its Supply Chain analysis off Access databases, probably still does. Just make copies and compact regularly and manage the data types
Pro-Office contribution. You can have an excel object on your forms to take advantage of excel formulas and data analysis tools I/O -ed to the form fields.Neat trick.I even open my workbook(s) on the form that loads when the access loads and access it in other places like functions.
Good point. For us, ODBC connections (in the past to a locally hosted MDB, for the past decade to a MySql server) are hosts to excel pivot tables, which make up the bulk of our reporting needs. This stuff runs our business...
I've been using Access since the mid 90s. I'm no expert but I am pretty comfortable with it. So far I've not found anything even comparable to it's ease of use, particularly with both the form builder and query builder. Even if I'm working on a php/html front end I'll still use the query builder in Access to write the sql statements. I'm anxious to see where you go with this as I really want to move away from Access as a front end.
It sounds like you and I have very similar experiences! I'm glad you're here and I hope these videos are useful, or at least interesting, to you. Take care!
@dreniarb We chose to stay with Access front end on purpose, but we did move the back end to a clustered MySql server. I agree, the form handling tand QBE hat is built in to access is terrific. The front end is probably the best part of access, which didn't need any recoding at all. I don't regret the effort we put in, it's been flawless for over a decade, way less expensive compared to recoding forms and business logic. If your data model is decent, (and you can face the idea of moving it, it's some learning and work), you can definitely put your data on a mysql backend. You will need a decent relational model on your data, and you'll want to go over all of your data and schema, make sure your relations and data types are ok, add timestamps, understand and deal with null, integer data types and whatnot. I got through it in a month or so. There quite a few migration tools available, (including MsSqlServer migration tool which is good, but there are a bunch of them, most aren't very expensive.) My goal was to keep 20 years of data intact, fix it as necessary, and be able to cut over to the new back end all at once when I comfortable. I tended to run the tools on the data, learn from them, create a test set, run the code against it. So I found every flaw in the migration tools (oh my god, i ended up using one tool for one thing, and then using another tool for the rest), but it was interesting, an I learned as I went, gained confidence, adjusted the relational model and data as I went. Check out Flyspeed SQL Query (very reasonably priced) if you like the QBE in Access, it's incredible, gives you QBE against any Sql backend. You can still use Access against ODBC links, but this gives you a direct way to query your my sql with GUI. For me, once I found that and HeidiSql to manage the Backend (You probably need to create "views" in your backend to replace certain FE queries, especially slow/complex ones and where you host 3rd party reporting like pivot tables in Excel)
Thanks Alan! I'm very glad it was useful. If you're interested in this type of development, I'm posting the first video in a series on developing solutions with Access front ends and SharePoint back ends next week. I hope you check it out. Take care my friend!
@@advantageapplications5712 thank you, I will be sure to follow along. I have so many spreadsheets I work with and have to keep updated and there’s a lot of double handing. This seems like the best option with my available resources outside of building my own app/website
I ve been using access for many years, got an all account program built with ms access. Any amateur can built great db and interfaces with access, u just need to be a db oriented mind. I just want/wish MS will never quit Access.
as a developer who creates applications that are client server and MS Access, you hit the nail on the head. For short its not an enterprise tool. But as a front end the same concept applies. Its a small desktop tool used for a small number of consumers.
Actually, SharePoint lists CAN be designed to support the functional equivalent of Referential Integrity between tables. They do so via the Lookup Field method. If you use Lookup fields in the local Access tables prior to exporting them to SharePoint, they are preserved. Or, if you design the SharePoint list with the appropriate Lookup Fields, Access recognizes and maintains those relationships.
Greetings from Canada George! Funny to find you here??? Actually, if you use the look up wizard and go back to the relationships window? You will see the same standard relationships. (so, relationships created with the lookup wizard shows in the regular relationships windows). And in fact the reverse is also true (you can use the lookup wizard against existing relationships to modify them - they both do the same thing). So, you are free to use relationships window to setup a relationship, ,or use the lookup wizard - both work seamless and result in quite much the same thing and result. Either way, these created relationships migrate to SharePoint with relationships intact. Unfortunately, my now 13 year old video used a web database for the sample migration, and thus I had to use the lookup wizard. I think it perhaps time I add a new YT video showing how this works without any references to "web stuff" So as a FYI? So, there is no requirement to use the lookup wizard - you can use the standard relationships window, and those relations will migrate up to SharePoint just the same with the relations working and intact on the SharePoint site, or even the low cost 365 account. So, even today, the low cost bottom feeder office 365 account (the one without including office or Access subscription for about $12 per month) still supports related Access tables. There is no requirement to use the lookup wizards for this - the standard relationships window can be used.
Ya know, I have heard that but I have never had any luck at all with it. In fact, a strange thing seems to happen where either the table can't be written to or a duplicate table is created alongside the "real" table with an underscore in its name. Have you experienced this yourself?
@advantageapplications5712 I've not seen that behavior. In fact you don't even have to use the relationship and lookup wizard, but can use the regular relationship window for this. The only special requirement is the pk has to be a auto number, and the foreign key is long number. So pk and fk can't be natural ones such as text. So unlike access, tables sent to SharePoint can only use a auto number set for such RI to work. And cascade delete is all you get. During up sizing all auto numbers are changed, so relationships must be set correctly before sending to SharePoint else relationships are lost due to auto numbers changing during the transfer. With relationships setup before transfer then access knows to update all child fk values to new pk
Interested to know your thoughts of linked tables in sharepoint vs dataverse for speed and stability. I've coded MS Access databases for over 25 years and still find them to be so powerful for a data front end in many scenarios and a data backend for small/micro businesses.
I couldn't agree more, I believe that is exactly where Access really shines in the modern work environment. As for tables linked to dataverse, I have to be honest, I have zero first-hand experience. All of the projects I have worked on, and currently support, store data in either SQL Server, SharePoint, or Oracle. But, my assumption would be that it would perform similarly to linking to data in SharePoint lists. I'm going to make a note of this topic though, and I'll do some research and make a video on it. I'm definitely interested. Thanks for checking out my channel, by the way!
Thank you for the video! I have database app with 25k rows of data. If I am not mistaken sharepoint list can only take 5k rows of data. Is SQL server my only option? Or I have other option similar to sharepoint. Thanks!
Hey! Thanks for watching my video and for the question. Actually, SharePoint lists can hold up to 30 million list items (records, in our case). The 5k limitation is only for what SharePoint can display in list views. And since our "views" are in Access, we aren't affected by it at all. I have one database, in particular, that has two tables with over 75,000 records each. Sometimes, users will run reports that return more than 5K records and it handles it with no issues. So, basically, as long as you are using SharePoint as the data storage and Access as your front end, you will not be hindered by the 5k view limit in SharePoint. Best of luck!
My problem with access is how to deploy the app, like the UI or form. I created a form that i needed the user to click on it at the start menu just like people do when they create one using UWP but hmmmmm. Is there a way to do that?
Hi ExcelPro, and thanks for checking out my video! My favorite way to deploy a solution that I've built in Access linked to a SharePoint (or SQL Server) backend, is to first make sure the user has a version of MS Access installed (at least Runtime) then allow them to download the front-end file (.accde, usually) from a SharePoint site or file-share. The first time the file runs, code executes to make sure it is launching from the location I want it to reside in and if it isn't, it installs itself there. I will cover how to do this later on the series I'm currently releasing. Each time the file is launched after that, a version check takes place to ensure the user has the most up-to-date copy of the database. That will make more sense when we walk through it together in the video series. I just released part 1 and I will try to release a new video in the series each week. Take care!
I am retired now but the last 25 or so years of my career were built on my Microsoft Access skills. I loved working with it but it worked best for a small department or office. My last employer was a large company so Access was not working for them. I understood that but I continued to use it for smaller needs.
Hello Rok! . I'm not sure I understood your question correctly, but if you're asking if I use AD, yes... I do. In solutions that are linked to SQL Server back ends, we use AD groups to manage permissions / authentication.
@@advantageapplications5712 permissions / authentication in MS Access and SharePoint .... how is that linked or could be with AD ( individuals or groups , tenants) you pull data ... so you could make an audit trail or version history how does synchronization not break the integrity of trail > one database synchronized with sharepoint using AD for who,where,when,what and also save&have audit trail / version history
One thing that I am not pretty sure I got it well, when you deletex the tables after placing them into sharepoint list, then you linked them to access...etc what about the old relationship?
That is a great question, and it is a bit confusing if you're used to explicitly defining relationships between tables in Access. The short answer is, SharePoint does not recognize the relationships defined in Access between tables. When those tables are exported to SharePoint, those relationships are lost. But, once those lists are linked to from Access, those relationships can be redefined. Or, you can just define the relationship when needed, like in a query or a control's row source property. I'm working on another video as we speak that takes a deeper dive into this topic. I expect to be ready to publish it next week. I hope you can check it out. I appreciate the view and comment!
@@advantageapplications5712 As I pointed out in other comments here? In fact your relationships do migrate correct to SharePoint (SP). There are "some" limitations", such as all relationships have to be based on the auto number PK, and the child records thus have to use a long number FK, and this is the most common setup in Access anyway. You can't however use say a text column for SP relationships, they must be the PK/FK and must be number. The other issue? You MUST in fact setup the relationships correctly BEFORE you sent to SP, else your related data will be messed up and lost! Why? Because during a up-size to SP your auto number PK values are re-set and changed, and that would in theory break the relationships to the child records, but if you setup the relationships BEFORE sending to SP, then it knows to re-number and update the child FK values correctly. I also suggest that you use a left join. If one wants to be 100%, and in fact 200% sure, then using the drop down in the table view, and launching the relationships wizard will 100% ensure your relationship is valid before being migrated to SP. However, the relationship window can be used, and they should correctly go up to SP. And yes, AFTER you migrate to SP, then the relationships WILL and DO show up in the client side (in Access) under the relationships window. So, note only can you setup relationships in Access before sending to SP? In fact you MUST do this!!! And in fact, even a simple drop list for a combo box from another table? Once again, I often don't setup enforced relationships for such a simple combo box dropdown, but if you going to set such data to SharePoint? Once again, you MUST setup the relationship, since as noted ALL and ANY PK auto number columns are changed during the up-size process, and if you don't have a valid relationship setup, then the migration can't know which child rows to update automatic for you. I have a older video here that shows how I was migrating Access web tables to SP, but they could have been regular tables, and note close in the video, note how the related tables FROM SP come back correctly to Access........ ruclips.net/video/3wdjYIby_b0/видео.html
No one can deny the power of MS Access especially when used a long with MS Excel for data exchange and analysis, despite being sabotaged since Web Apps were sadly deprecated by Microsoft.
That is definitely one of the most frustrating things about Microsoft... they will completely turn their backs on existing tech that people love, use, and depend on.
😅Yes, it can support small scale Etl of raw data and send it to email or folders. We use access to connect to 150 views in Sql and we email these to users it works great using Vba and DAO. We're not able to email directly from sql...we prefer to persist data in Sql and also use access to front end small datasets into sql and edit data
Hey Damjan! Interesting. I only have experience working in a Microsoft environment. All of the clients I've worked for use Windows for their computing needs. Access, coupled with the Power Platform and SharePoint has served our needs really well for department level applications and even a couple site-wide tools. I hope you can check out my series on building custom solutions using MS Access as a front end, SharePoint as a backend, and extending capabilities using the Power Platform. Take care, my friend!
Great video and congrats on the video doing so well. I look at MS Access as I do any tool. There a certain reasons I would use a jigsaw and certain reasons I might use a miter saw. Neither is necessarily better than the other (it depends on the project) and neither are going anywhere soon. Anyway, great video!
Hi. I have played with Access and Sharepoint lists and I found that if data is added to the List it is not seen in access until you refresh the table manually by pressing the Refresh button. How does this pan out if there are multiple users using the front end and each is adding data? Appreciate your insight on this point.
Hi David, that is interesting. The solutions I've made using Access as a front end and SharePoint as a backend always refresh in real time. Now, if I already have a form or query open displaying data and the underlying table data is modified by another user elsewhere, my view of the data doesn't reflect that change until the form or query is re-opened or refreshed. But that's the case with the vast majority of applications, including web based solutions. The current view must always be refreshed to get the most up-to-date data. I hope that makes sense. Thank you for watching my video! I have more to come in regards to building solutions using Access linked to SharePoint.
@@advantageapplications5712 Thank you for the swift response and clear answer. Maybe I was expecting too much as other Microsoft applications using SharePoint are updated in real time with the ability to see changes made by others instantly. I look forward to your other videos.
Hello Adobestock, and thanks for watching my video. Yes, absolutely... and the beauty of this architecture, if the Access front end is saved locally on each user's workstation, is that there is only ever one user in the Access portion of the solution. All of the multi-user activity is handled in SQL Server or, in the case of this series I'm currently creating, SharePoint. And they (SQL Server and SharePoint) are of course meant for just that type of use.
one problem with access I had is that it's just easier to do things with a programming language, and in order to build a good database you have to be a developer to a certain degree. And users that need things fast just use excel as db.
I agree with you 100% on both points; the need to be a bit of a developer to create a good or useful DB in Access and also that people tend to go with Excel for ease of use. At some point, those Excel databases tend to become unwieldy and even break. From my personal experience it is usually best to create the solution in a suite intended for databases. The good thing about Access is that, relatively speaking, it is an easy platform to learn to design (and code) solutions in. Thanks for the great comment and thanks for checking out my video!
Excel is a data storage and manipulation tool but it is not a database. Power query has improved the use of excel for querying data but it's still not a database.
Can I give one of my customers access to a database that has an Access front-end and a SQL Server or SharePoint back-end? They are a “Mac Only” customer too 😅
Hey, and thanks for checking out my video! Giving access to your user is definitely possible, all you have to do is add the user to your SharePoint site and set them up with the permissions you want them to have. Then, when you give them the copy of the Access front end with the linked tables, it will connect to the data. Unfortunately, Access won't run on Mac without using some type of Windows emulator and even then it may be glitchy.
Unfortunately, there is not a Access client (desktop) for the Mac. This has always been a "hope" that a version of Access would come out for the Mac, but it is simply not a choice we have right now. You can certainly hit the SharePoint site with data from Access, but there is no option to install + use Access on a Mac at this point in time.
Access is still a thing for small companies and the government; but very much obsolete for other companies that are progressing toward Cloud Database, tools and analytics, such as Azure, Databricks, and Snow Flakes.
I respectfully disagree. I use Access (linked to SharePoint and SQL Server) to support the work processes of several chemical manufacturers and some of the solutions I build are mission critical. It is the very fact that Access can so easily connect to cloud-based data like SQL Server and SharePoint that makes it powerful. Coupled with the control and automation you can program into it via VBA, and the fact that you can extend this type of solution with newer technologies like Flow, Power BI, and PowerApps; it is a very powerful tool.
@@advantageapplications5712 Agree but in the companies that I worked for many IT departments and executive leaders have made it clear that Access DB is obsolete and can no longer support big data analytics nowadays with Fact-Dimension data modeling, analytics, and prediction. Many individuals who are only strong in VBA and Access and without SQL background have been laid off. Companies with budget also moving away from on premises databases and into Cloud. Since the world leaped forward with internet speed where some residential area can now have at least 2 Gbps, the database also got drastically evolved. Just like rarely people will use 2.5 MB floppy disk now, when the SDLC and hardware support gradually dies down in the next 10-20 years for the technology that we have established 20 years ago. Unless Access become the new Cloud platform that can one-shot connect to all kinds of data legacy platform and modeling for data migration.
Actually access was one of the first products that had some built in parts for working with SQL Azure. So access supports cloud based back ends such as SharePoint or SQL Azure edition- both of which are cloud based.
Without consideration to anything else, like: cost to own and maintain? Data storage fees? Compute fees? What stack will the app reside on and what are the trade offs for choosing it? How, where, and by whom will the app be used? How long will it take and how much will it cost to add new functionality to the app if business processes change? Simply hiring developers to build a "real" app is a fashion statement and often over extends company budget and makes them beholden to the developer's availability and pricing instead of the client having ownership of their tool. In my experience, if you can demo it in Access, then it is intended to be used in a PC environment and therefore is absolutely worth considering building in Access with a SQL Server or SharePoint back end. And I've helped many companies get out of the bad relationships with "real apps". ;)
I don't know exactly where the line is but eighty users across two different countries (US and India) on two different continents is definitely too many.
@@etexas lol... sounds like you have some direct experience with that scenario my friend. Was this solution hosted entirely in Access? I have one Access DB connected to a SharePoint back end that serves up to 200 concurrent users across three states and does it like a champ. BUT, because the front end (the Access file) resides on each user's workstation, there is only ever one single user in the Access portion of the solution at any time. All of the multi-user activity is on SharePoint, which was built for that type of load.
Well, I would say that depends on how quickly, cost effectively, and efficiently the need of the client can be met and what the cost of long term ownership of the developed solution is. I've managed to supplant several web-based apps with the very type of solution I will be covering in this series. Now that my clients see how effective this type of app can be, and how simple they are to create and maintain (with often much lower costs) they now prefer to go this route in most cases.
@@advantageapplications5712 I also like Access and I recognize that you can quickly acquire good knowledge, but here you lock the client in the world of Microsoft and which is paid and you can only communicate with the internal world of the company, for employees, ok we can set up remote offices without too much difficulty but if your clientele is outside and you ask them to fill out forms, you certainly need to put in fairly sophisticated security to not not get hacked. In any case, I have never seen a solution implemented for this specific case with Access. I agree with you, each case must be studied to adopt the right solution, but we can spend hours of development to realize that our interface is too limiting because people arrive with OS other than Windows, etc... I therefore think that we need from the start towards a solution which can be directly universal. Your video remains very interesting, good work
@@advantageapplications5712 I ended up using a packaged bookkeeping program, it was easier came with annual updates and covered employee time management plus more, also was able to deal with tax etc more easily. No issues with versions, and when I took my own time into account was a fraction of the cost. I never opened MSACCESS again.
I never any experience with FoxPro, myself. Everyone that I've talked to who has used it loves it though. They must have gotten something right to have that kind of loyalty. Thanks for watching!
Ya know, I never actually used macros in Access. The implementation seemed limited and clunky to me, especially when I could accomplish the same thing with a finer degree of control using VBA. Thanks for checking out my video!
Access is a long way from limited. It wouldn't be a good idea to try to implement anything using macros, but VBA is about a capable as any language, and is seriously capable for deployment via DAO ODBC against any Sql server, with lots of advantages in terms of built in tools for presenting and collecting data
@@zincfive as far as macros, I didn’t realize it at the time. Using macros is a lot easier than VBA, especially if you have zero experience with either of them. Eventually I learned to incorporate VBA.
@@ad7711x good for you. There are lots of choices of programming languages, but with all the built in db functionality Access is really unsurpassed for solving problems quickly in the windows environment, plus as you learn, you can develop applications that are quite complex.
Hi Richard, I would say it isn't good for hundreds of thousands of records. But I have several Access / SharePoint solutions in use that many tens of thousands of records and perform very well.
Access runs great against MySql or SqlServer. Plenty fast. You wouldn't build an application from scratch with it today, but if you have an app with decent code and a good relational data set, you can keep your code, and move your data to a Sql server of some sort, much less work.
I always try to avoid microsoft products. Microsot can ditch a product, language instantly... I can do the same with open source databases and using scripting languages. It will make one develep himself
Is Microsoft still viable.... can you survive MSCustomer support? Authenticator app update clears your settings, you can't sign back in because it wants a code from authenticator, you can't get code coz you're not signed in... you cant get support online without a code. So you phone... 6 hours of calls, mostly on hold and you find the solution is easy, MS data privacy team simply has to disable MFA. Only... data team wont answer the phone, they just disconnect you after an hours or so... back to an advocate... and "oh... just email the team raising a privacy concern, they will get back to you... its the only way to contact them. This is the agreed approach as they are currently overwhelmed"... 3 days later an email discussing GDPR and a bunch of privacy links. Not even an acknowledgement of the problem. Microsoft are denying me access to my data and thats illegal, they've been fined for it before and no doubt they'll get fined again. Hardly surprising from a company based in a country that bombs children with support based in a country where they simply don't do that sort of thing...
I hope you get access to your data. If you have such strong political aversions to U.S. based companies perhaps you should look elsewhere for your technology needs. I'm sure you wouldn't want to compromise your principles. I personally have not had any trouble with MFA or accessing my data on SharePoint... either on my own projects or concerning the companies I contract with.
@@advantageapplications5712 Those are not strong opinions, just observations. America has killed more people since WWII than the nazis. What its doing in Palestine is obscene, the act of a very sick people. But I guess you guys would rather spend your money bombing children than having things like free healthcare or a better standard of living, maybe even tidy up your streets a bit... Seriously, you could have had free healthcare for all for less than you spend on genocide... The world is done with it. As for Microsoft etc. I'd ditch them in a heartbeat, in fact I only use MS products because clients do.
Actually, when Access is linked to data on SharePoint most of its limitations are completely overcome. And it's much easier to build powerful apps in Access than even modern, so-called "no code" / "low code" environments. And, since the data is on SharePoint, you can leverage and integrate other tools and technologies like Flow, Power BI, and Power Apps. My upcoming videos are going to take deeper dive into those very topics. I hope you can stick around and check them out.
Another massive plus to using Access, aside from it's use as a rapid test bed, is that you can create your own custom VBA functions and use those directly inside your sql string/query. This allows you to extend the existing query functionality in extremely powerful ways. Of course, add this to your own custom forms (and more custom VBA) and you take things to the next level.
Yes, absolutely, that is awesome. I need to do a video on that as well. Thanks for checking out my video!
As far as I'm concerned Access is great database for the personal applications to which I put it. It's never going to be an Oracle or SQL Server but I don't believe it was meant to be that. I find Access to be very useful, especially with VBA and DAO as well as the various wizards. I'm in for the long-term. Thanks for your challenging question.
Very well said, Dave. I believe you're absolutely right. Knowing what Access is, and what it is not, is key. Thank you for checking out this video!
@@advantageapplications5712 I like your style. Good to see some more Access content, even VBA. I'm an advanced beginner :>). I've been an Excel user for years, I'm transitioning to Access, it is such a cool db. Keep up the good work mate! I've subscribed.
Oracle and SQL Server are database servers, MSAccess is a file server. They are different server types
@charlesbaldo
True, but access makes a great client program to sql server. I've not used access as the backend for more than 10 years, but that doesn't mean access as the front end is a problem. In effect you thus use access with sql server or SharePoint as the back end. Hence the issues of scaling number of users becomes sql server's problem and not that of using access as the front end to such databases.
@@Albertkallal I am working at a US corporation now that used Access as a Front End for 20 years. It was used as an Enterprise client. They worked well
This brings back a lot of memories. For years I used to make a lot of different MsAccess databases on a server with like users frontends. Often 20 to 40 users. Even created an automatic update system for the users based on version numbers. Very handy for the constant tweaks they wanted. After a while they became slow and you had to compress every table manually. For that I had to remove every link and connect it all back again. I always found the downside you could not turn the user frontends into an executable. Everyone had to have the whole Office Pro suite. I can't remember anything like Sharepoint already existing. Tried various SQL databases, but it somehow never worked too well. I will be watching how this works out.
Since access 2007 the runtime package been free. That means unlimited copies of your application can be deployed for free and without needing any office license.
Oh yes, I've definitely faced some of those same issues. When the companies I work for adopted Office 365, SharePoint, and the Power Platform, they thought they would be retiring Access. But once I figured out that Access could actually interface with these new technologies, they loved it. We could ease into the "new thing" and reduce user learning curve. Someone once said that Microsoft doesn't advance by evolution but by revolution. I find that to be very accurate. This made it seem less jarring.
@@advantageapplications5712 We were lucky to have a good relational model (and I have a background in database development from my education in the 70's and 80's) on our Access 98-era back-end accounting package, which we purchased for maybe 700 dollars with source code in 1999. We were able to move the back end to MySql, which took a bit of head scratching, but actually wasn't that bad, works flawlessly, totally "clusterable" and "cloud ready". MDE's are actually compiled front ends, and the runtimes are free. At that point, who cares what the front end is coded in? As a small business we don't have to be concerned about having a maintenance contract, so we keep a current version of access licensed for DEV, everything else is free. Frankly, there is very very little that was added in the last 25 years to SQL, every day I'm impressed how complete the VBA/Access environment was back then. If I had chased "modernity" back then, I'd have literally hundreds of thousands of dollars less in my retirement account. And he best thing, is that ODBC and Excel pivot tables are the most incredible reporting engines. So for us, Yes. Totally Viable.
I love Access for learning, for building out simple databases. The firm I worked for, one of the largest in the UK ran most of its Supply Chain analysis off Access databases, probably still does. Just make copies and compact regularly and manage the data types
That is solid advice for sure. Thanks for checking out my video!!
I use it to prototype....excellent for smaller rapid dB apps.
Yes, totally agree.
Pro-Office contribution. You can have an excel object on your forms to take advantage of excel formulas and data analysis tools I/O -ed to the form fields.Neat trick.I even open my workbook(s) on the form that loads when the access loads and access it in other places like functions.
That's an awesome pro tip, thank you for sharing it!!
Good point. For us, ODBC connections (in the past to a locally hosted MDB, for the past decade to a MySql server) are hosts to excel pivot tables, which make up the bulk of our reporting needs. This stuff runs our business...
I've been using Access since the mid 90s. I'm no expert but I am pretty comfortable with it. So far I've not found anything even comparable to it's ease of use, particularly with both the form builder and query builder. Even if I'm working on a php/html front end I'll still use the query builder in Access to write the sql statements.
I'm anxious to see where you go with this as I really want to move away from Access as a front end.
It sounds like you and I have very similar experiences! I'm glad you're here and I hope these videos are useful, or at least interesting, to you. Take care!
@dreniarb We chose to stay with Access front end on purpose, but we did move the back end to a clustered MySql server. I agree, the form handling tand QBE hat is built in to access is terrific. The front end is probably the best part of access, which didn't need any recoding at all. I don't regret the effort we put in, it's been flawless for over a decade, way less expensive compared to recoding forms and business logic.
If your data model is decent, (and you can face the idea of moving it, it's some learning and work), you can definitely put your data on a mysql backend. You will need a decent relational model on your data, and you'll want to go over all of your data and schema, make sure your relations and data types are ok, add timestamps, understand and deal with null, integer data types and whatnot. I got through it in a month or so. There quite a few migration tools available, (including MsSqlServer migration tool which is good, but there are a bunch of them, most aren't very expensive.) My goal was to keep 20 years of data intact, fix it as necessary, and be able to cut over to the new back end all at once when I comfortable. I tended to run the tools on the data, learn from them, create a test set, run the code against it. So I found every flaw in the migration tools (oh my god, i ended up using one tool for one thing, and then using another tool for the rest), but it was interesting, an I learned as I went, gained confidence, adjusted the relational model and data as I went.
Check out Flyspeed SQL Query (very reasonably priced) if you like the QBE in Access, it's incredible, gives you QBE against any Sql backend. You can still use Access against ODBC links, but this gives you a direct way to query your my sql with GUI. For me, once I found that and HeidiSql to manage the Backend (You probably need to create "views" in your backend to replace certain FE queries, especially slow/complex ones and where you host 3rd party reporting like pivot tables in Excel)
This is exactly what I have been searching for! Thank you so much!
Thanks Alan! I'm very glad it was useful.
If you're interested in this type of development, I'm posting the first video in a series on developing solutions with Access front ends and SharePoint back ends next week. I hope you check it out.
Take care my friend!
@@advantageapplications5712 thank you, I will be sure to follow along.
I have so many spreadsheets I work with and have to keep updated and there’s a lot of double handing. This seems like the best option with my available resources outside of building my own app/website
I ve been using access for many years, got an all account program built with ms access. Any amateur can built great db and interfaces with access, u just need to be a db oriented mind. I just want/wish MS will never quit Access.
as a developer who creates applications that are client server and MS Access, you hit the nail on the head. For short its not an enterprise tool. But as a front end the same concept applies. Its a small desktop tool used for a small number of consumers.
Hi Charles, well said, sir.
Actually, SharePoint lists CAN be designed to support the functional equivalent of Referential Integrity between tables. They do so via the Lookup Field method. If you use Lookup fields in the local Access tables prior to exporting them to SharePoint, they are preserved. Or, if you design the SharePoint list with the appropriate Lookup Fields, Access recognizes and maintains those relationships.
Greetings from Canada George! Funny to find you here???
Actually, if you use the look up wizard and go back to the relationships window?
You will see the same standard relationships. (so, relationships created with the lookup wizard shows in the regular relationships windows). And in fact the reverse is also true (you can use the lookup wizard against existing relationships to modify them - they both do the same thing).
So, you are free to use relationships window to setup a relationship, ,or use the lookup wizard - both work seamless and result in quite much the same thing and result.
Either way, these created relationships migrate to SharePoint with relationships intact.
Unfortunately, my now 13 year old video used a web database for the sample migration, and thus I had to use the lookup wizard. I think it perhaps time I add a new YT video showing how this works without any references to "web stuff"
So as a FYI?
So, there is no requirement to use the lookup wizard - you can use the standard relationships window, and those relations will migrate up to SharePoint just the same with the relations working and intact on the SharePoint site, or even the low cost 365 account.
So, even today, the low cost bottom feeder office 365 account (the one without including office or Access subscription for about $12 per month) still supports related Access tables. There is no requirement to use the lookup wizards for this - the standard relationships window can be used.
Ya know, I have heard that but I have never had any luck at all with it. In fact, a strange thing seems to happen where either the table can't be written to or a duplicate table is created alongside the "real" table with an underscore in its name. Have you experienced this yourself?
@advantageapplications5712
I've not seen that behavior.
In fact you don't even have to use the relationship and lookup wizard, but can use the regular relationship window for this.
The only special requirement is the pk has to be a auto number, and the foreign key is long number. So pk and fk can't be natural ones such as text. So unlike access, tables sent to SharePoint can only use a auto number set for such RI to work.
And cascade delete is all you get.
During up sizing all auto numbers are changed, so relationships must be set correctly before sending to SharePoint else relationships are lost due to auto numbers changing during the transfer. With relationships setup before transfer then access knows to update all child fk values to new pk
Interested to know your thoughts of linked tables in sharepoint vs dataverse for speed and stability. I've coded MS Access databases for over 25 years and still find them to be so powerful for a data front end in many scenarios and a data backend for small/micro businesses.
I couldn't agree more, I believe that is exactly where Access really shines in the modern work environment. As for tables linked to dataverse, I have to be honest, I have zero first-hand experience. All of the projects I have worked on, and currently support, store data in either SQL Server, SharePoint, or Oracle. But, my assumption would be that it would perform similarly to linking to data in SharePoint lists.
I'm going to make a note of this topic though, and I'll do some research and make a video on it. I'm definitely interested.
Thanks for checking out my channel, by the way!
Thank you for the video! I have database app with 25k rows of data. If I am not mistaken sharepoint list can only take 5k rows of data. Is SQL server my only option? Or I have other option similar to sharepoint. Thanks!
Hey! Thanks for watching my video and for the question. Actually, SharePoint lists can hold up to 30 million list items (records, in our case). The 5k limitation is only for what SharePoint can display in list views. And since our "views" are in Access, we aren't affected by it at all. I have one database, in particular, that has two tables with over 75,000 records each. Sometimes, users will run reports that return more than 5K records and it handles it with no issues. So, basically, as long as you are using SharePoint as the data storage and Access as your front end, you will not be hindered by the 5k view limit in SharePoint.
Best of luck!
My problem with access is how to deploy the app, like the UI or form. I created a form that i needed the user to click on it at the start menu just like people do when they create one using UWP but hmmmmm. Is there a way to do that?
Hi ExcelPro, and thanks for checking out my video!
My favorite way to deploy a solution that I've built in Access linked to a SharePoint (or SQL Server) backend, is to first make sure the user has a version of MS Access installed (at least Runtime) then allow them to download the front-end file (.accde, usually) from a SharePoint site or file-share. The first time the file runs, code executes to make sure it is launching from the location I want it to reside in and if it isn't, it installs itself there. I will cover how to do this later on the series I'm currently releasing. Each time the file is launched after that, a version check takes place to ensure the user has the most up-to-date copy of the database.
That will make more sense when we walk through it together in the video series. I just released part 1 and I will try to release a new video in the series each week.
Take care!
I am retired now but the last 25 or so years of my career were built on my Microsoft Access skills. I loved working with it but it worked best for a small department or office. My last employer was a large company so Access was not working for them. I understood that but I continued to use it for smaller needs.
It is an incredibly underrated, often overlooked, tool in the kit. Thanks for watching my video and enjoy your retirement!
my last time was 2008, thanks for the heads up (Breaking Bad too)😄
lol... thanks for checking it out!
Another Excellent tutorial. All thumbs up Rick, already subscribed. Thank you so much for your time to prepare this valuable info
Thank you for that very kind feedback, Jojo! Very much appreciated my friend.
Active directory ... to record a person using AdB or chose from to put in record?
Hello Rok! . I'm not sure I understood your question correctly, but if you're asking if I use AD, yes... I do. In solutions that are linked to SQL Server back ends, we use AD groups to manage permissions / authentication.
@@advantageapplications5712 permissions / authentication in MS Access and SharePoint .... how is that linked or could be with AD ( individuals or groups , tenants) you pull data ... so you could make an audit trail or version history how does synchronization not break the integrity of trail > one database synchronized with sharepoint using AD for who,where,when,what and also save&have audit trail / version history
One thing that I am not pretty sure I got it well, when you deletex the tables after placing them into sharepoint list, then you linked them to access...etc what about the old relationship?
That is a great question, and it is a bit confusing if you're used to explicitly defining relationships between tables in Access. The short answer is, SharePoint does not recognize the relationships defined in Access between tables. When those tables are exported to SharePoint, those relationships are lost. But, once those lists are linked to from Access, those relationships can be redefined. Or, you can just define the relationship when needed, like in a query or a control's row source property.
I'm working on another video as we speak that takes a deeper dive into this topic. I expect to be ready to publish it next week. I hope you can check it out.
I appreciate the view and comment!
@@advantageapplications5712
As I pointed out in other comments here? In fact your relationships do migrate correct to SharePoint (SP). There are "some" limitations", such as all relationships have to be based on the auto number PK, and the child records thus have to use a long number FK, and this is the most common setup in Access anyway.
You can't however use say a text column for SP relationships, they must be the PK/FK and must be number.
The other issue?
You MUST in fact setup the relationships correctly BEFORE you sent to SP, else your related data will be messed up and lost!
Why?
Because during a up-size to SP your auto number PK values are re-set and changed, and that would in theory break the relationships to the child records, but if you setup the relationships BEFORE sending to SP, then it knows to re-number and update the child FK values correctly.
I also suggest that you use a left join.
If one wants to be 100%, and in fact 200% sure, then using the drop down in the table view, and launching the relationships wizard will 100% ensure your relationship is valid before being migrated to SP. However, the relationship window can be used, and they should correctly go up to SP. And yes, AFTER you migrate to SP, then the relationships WILL and DO show up in the client side (in Access) under the relationships window.
So, note only can you setup relationships in Access before sending to SP?
In fact you MUST do this!!!
And in fact, even a simple drop list for a combo box from another table? Once again, I often don't setup enforced relationships for such a simple combo box dropdown, but if you going to set such data to SharePoint?
Once again, you MUST setup the relationship, since as noted ALL and ANY PK auto number columns are changed during the up-size process, and if you don't have a valid relationship setup, then the migration can't know which child rows to update automatic for you.
I have a older video here that shows how I was migrating Access web tables to SP, but they could have been regular tables, and note close in the video, note how the related tables FROM SP come back correctly to Access........
ruclips.net/video/3wdjYIby_b0/видео.html
No one can deny the power of MS Access especially when used a long with MS Excel for data exchange and analysis, despite being sabotaged since Web Apps were sadly deprecated by Microsoft.
That is definitely one of the most frustrating things about Microsoft... they will completely turn their backs on existing tech that people love, use, and depend on.
😅Yes, it can support small scale Etl of raw data and send it to email or folders. We use access to connect to 150 views in Sql and we email these to users it works great using Vba and DAO. We're not able to email directly from sql...we prefer to persist data in Sql and also use access to front end small datasets into sql and edit data
Hey! Thanks for watching and commenting... that sounds like a perfect use-case for Access tied to SQL Server. Spot on.
This is going to be exciting. Thanks for sharing
Thanks so much for the positive feedback!!
Yes, if you want to export the data of an old applicaiton, to make an sqlite port of it :P, so it will work on any os.
Hey Damjan! Interesting. I only have experience working in a Microsoft environment. All of the clients I've worked for use Windows for their computing needs. Access, coupled with the Power Platform and SharePoint has served our needs really well for department level applications and even a couple site-wide tools.
I hope you can check out my series on building custom solutions using MS Access as a front end, SharePoint as a backend, and extending capabilities using the Power Platform.
Take care, my friend!
Great video and congrats on the video doing so well. I look at MS Access as I do any tool. There a certain reasons I would use a jigsaw and certain reasons I might use a miter saw. Neither is necessarily better than the other (it depends on the project) and neither are going anywhere soon.
Anyway, great video!
I think you put it perfectly... that's exactly right. It's a tool with advantageous and disadvantages.
Great user name, btw! I got a kick out of that.
Hi. I have played with Access and Sharepoint lists and I found that if data is added to the List it is not seen in access until you refresh the table manually by pressing the Refresh button. How does this pan out if there are multiple users using the front end and each is adding data? Appreciate your insight on this point.
Hi David, that is interesting. The solutions I've made using Access as a front end and SharePoint as a backend always refresh in real time. Now, if I already have a form or query open displaying data and the underlying table data is modified by another user elsewhere, my view of the data doesn't reflect that change until the form or query is re-opened or refreshed. But that's the case with the vast majority of applications, including web based solutions. The current view must always be refreshed to get the most up-to-date data.
I hope that makes sense. Thank you for watching my video! I have more to come in regards to building solutions using Access linked to SharePoint.
@@advantageapplications5712 Thank you for the swift response and clear answer. Maybe I was expecting too much as other Microsoft applications using SharePoint are updated in real time with the ability to see changes made by others instantly.
I look forward to your other videos.
can we say access front end, sql back end good idea for mid or big size business?
Hello Adobestock, and thanks for watching my video.
Yes, absolutely... and the beauty of this architecture, if the Access front end is saved locally on each user's workstation, is that there is only ever one user in the Access portion of the solution. All of the multi-user activity is handled in SQL Server or, in the case of this series I'm currently creating, SharePoint. And they (SQL Server and SharePoint) are of course meant for just that type of use.
@@advantageapplications5712 Great tips from you, thanks a lot.
one problem with access I had is that it's just easier to do things with a programming language, and in order to build a good database you have to be a developer to a certain degree. And users that need things fast just use excel as db.
I agree with you 100% on both points; the need to be a bit of a developer to create a good or useful DB in Access and also that people tend to go with Excel for ease of use. At some point, those Excel databases tend to become unwieldy and even break. From my personal experience it is usually best to create the solution in a suite intended for databases. The good thing about Access is that, relatively speaking, it is an easy platform to learn to design (and code) solutions in.
Thanks for the great comment and thanks for checking out my video!
@@advantageapplications5712 Great video by the way.
Excel is a data storage and manipulation tool but it is not a database. Power query has improved the use of excel for querying data but it's still not a database.
Can I give one of my customers access to a database that has an Access front-end and a SQL Server or SharePoint back-end? They are a “Mac Only” customer too 😅
Hey, and thanks for checking out my video!
Giving access to your user is definitely possible, all you have to do is add the user to your SharePoint site and set them up with the permissions you want them to have. Then, when you give them the copy of the Access front end with the linked tables, it will connect to the data.
Unfortunately, Access won't run on Mac without using some type of Windows emulator and even then it may be glitchy.
Unfortunately, there is not a Access client (desktop) for the Mac. This has always been a "hope" that a version of Access would come out for the Mac, but it is simply not a choice we have right now. You can certainly hit the SharePoint site with data from Access, but there is no option to install + use Access on a Mac at this point in time.
Excellent tutorial about Access. Thanks for sharing👍❤
Thank you for that kind feedback, and thanks for watching!
Access is still a thing for small companies and the government; but very much obsolete for other companies that are progressing toward Cloud Database, tools and analytics, such as Azure, Databricks, and Snow Flakes.
I respectfully disagree. I use Access (linked to SharePoint and SQL Server) to support the work processes of several chemical manufacturers and some of the solutions I build are mission critical. It is the very fact that Access can so easily connect to cloud-based data like SQL Server and SharePoint that makes it powerful. Coupled with the control and automation you can program into it via VBA, and the fact that you can extend this type of solution with newer technologies like Flow, Power BI, and PowerApps; it is a very powerful tool.
@@advantageapplications5712 Agree but in the companies that I worked for many IT departments and executive leaders have made it clear that Access DB is obsolete and can no longer support big data analytics nowadays with Fact-Dimension data modeling, analytics, and prediction. Many individuals who are only strong in VBA and Access and without SQL background have been laid off. Companies with budget also moving away from on premises databases and into Cloud. Since the world leaped forward with internet speed where some residential area can now have at least 2 Gbps, the database also got drastically evolved. Just like rarely people will use 2.5 MB floppy disk now, when the SDLC and hardware support gradually dies down in the next 10-20 years for the technology that we have established 20 years ago. Unless Access become the new Cloud platform that can one-shot connect to all kinds of data legacy platform and modeling for data migration.
Actually access was one of the first products that had some built in parts for working with SQL Azure. So access supports cloud based back ends such as SharePoint or SQL Azure edition- both of which are cloud based.
Access is great for showing a proof of concept. Afterwards, hire developers to make the “real” application.
Without consideration to anything else, like: cost to own and maintain? Data storage fees? Compute fees? What stack will the app reside on and what are the trade offs for choosing it? How, where, and by whom will the app be used? How long will it take and how much will it cost to add new functionality to the app if business processes change?
Simply hiring developers to build a "real" app is a fashion statement and often over extends company budget and makes them beholden to the developer's availability and pricing instead of the client having ownership of their tool.
In my experience, if you can demo it in Access, then it is intended to be used in a PC environment and therefore is absolutely worth considering building in Access with a SQL Server or SharePoint back end. And I've helped many companies get out of the bad relationships with "real apps". ;)
This is great, thank you. definitely a new sub.
Thank you my friend and welcome!
I don't know exactly where the line is but eighty users across two different countries (US and India) on two different continents is definitely too many.
ask me how I know lol
@@etexas lol... sounds like you have some direct experience with that scenario my friend. Was this solution hosted entirely in Access?
I have one Access DB connected to a SharePoint back end that serves up to 200 concurrent users across three states and does it like a champ. BUT, because the front end (the Access file) resides on each user's workstation, there is only ever one single user in the Access portion of the solution at any time. All of the multi-user activity is on SharePoint, which was built for that type of load.
I always thought the Access database builders and wizards were simpleminded when compared to Visual FoxPro (or dBase) database wizards and builders.
How so?
Well done, Sir!
Thanks! And thank you for watching!
This was excellent!!! thank you
Thanks for watching my video and for that very kind feedback!
Now, it is preferable to turn to a web interface with a language like php or asp It is much more universal
Well, I would say that depends on how quickly, cost effectively, and efficiently the need of the client can be met and what the cost of long term ownership of the developed solution is. I've managed to supplant several web-based apps with the very type of solution I will be covering in this series. Now that my clients see how effective this type of app can be, and how simple they are to create and maintain (with often much lower costs) they now prefer to go this route in most cases.
@@advantageapplications5712 I also like Access and I recognize that you can quickly acquire good knowledge, but here you lock the client in the world of Microsoft and which is paid and you can only communicate with the internal world of the company, for employees, ok we can set up remote offices without too much difficulty but if your clientele is outside and you ask them to fill out forms, you certainly need to put in fairly sophisticated security to not not get hacked. In any case, I have never seen a solution implemented for this specific case with Access.
I agree with you, each case must be studied to adopt the right solution, but we can spend hours of development to realize that our interface is too limiting because people arrive with OS other than Windows, etc... I therefore think that we need from the start towards a solution which can be directly universal.
Your video remains very interesting, good work
I loved MSACCESS but unlike EXCEL every new step forward created problems with backwards compatibility, eventually gave up and used other products.
Oh yeah? I hate to hear that. What did you ultimately wind up using?
@@advantageapplications5712 I ended up using a packaged bookkeeping program, it was easier came with annual updates and covered employee time management plus more, also was able to deal with tax etc more easily. No issues with versions, and when I took my own time into account was a fraction of the cost. I never opened MSACCESS again.
Today I see it has a ODBC client to Oracle.
Yes, definitely.
It will never replace Visual Foxpro, which will never replace Foxpro OG...
I never any experience with FoxPro, myself. Everyone that I've talked to who has used it loves it though. They must have gotten something right to have that kind of loyalty. Thanks for watching!
Nice anyalisis!👍
Thank you my friend!
Access is the best.
It certainly is under rated and often overlooked entirely. Thanks for watching my video!
I can’t imagine Hector Salamanca working many overtime hours.
;)
MS Access is too limited. And macros makes it a nightmare to deploy among multiple machines. It taught me a lot though.
Ya know, I never actually used macros in Access. The implementation seemed limited and clunky to me, especially when I could accomplish the same thing with a finer degree of control using VBA.
Thanks for checking out my video!
Access is a long way from limited. It wouldn't be a good idea to try to implement anything using macros, but VBA is about a capable as any language, and is seriously capable for deployment via DAO ODBC against any Sql server, with lots of advantages in terms of built in tools for presenting and collecting data
@@zincfive as far as macros, I didn’t realize it at the time. Using macros is a lot easier than VBA, especially if you have zero experience with either of them. Eventually I learned to incorporate VBA.
@@ad7711x good for you. There are lots of choices of programming languages, but with all the built in db functionality Access is really unsurpassed for solving problems quickly in the windows environment, plus as you learn, you can develop applications that are quite complex.
Sharepoint list is no good for thousands of records though, at least that's what I found. Far too slow.
Hi Richard, I would say it isn't good for hundreds of thousands of records. But I have several Access / SharePoint solutions in use that many tens of thousands of records and perform very well.
@@advantageapplications5712 yes I think that's a fair comment.
Access runs great against MySql or SqlServer. Plenty fast. You wouldn't build an application from scratch with it today, but if you have an app with decent code and a good relational data set, you can keep your code, and move your data to a Sql server of some sort, much less work.
I always try to avoid microsoft products. Microsot can ditch a product, language instantly... I can do the same with open source databases and using scripting languages. It will make one develep himself
Well, I certainly can't argue with you there, my friend. Someone once said Microsoft advances by revolution instead of evolution.
yes it is
Couldn't agree more Juan! Thanks for the feedback my friend.
Here's a VERY good reason, lets say the database needs to be worked where there is no internet. @@advantageapplications5712
Is Microsoft still viable.... can you survive MSCustomer support? Authenticator app update clears your settings, you can't sign back in because it wants a code from authenticator, you can't get code coz you're not signed in... you cant get support online without a code. So you phone...
6 hours of calls, mostly on hold and you find the solution is easy, MS data privacy team simply has to disable MFA. Only... data team wont answer the phone, they just disconnect you after an hours or so... back to an advocate... and "oh... just email the team raising a privacy concern, they will get back to you... its the only way to contact them. This is the agreed approach as they are currently overwhelmed"...
3 days later an email discussing GDPR and a bunch of privacy links. Not even an acknowledgement of the problem.
Microsoft are denying me access to my data and thats illegal, they've been fined for it before and no doubt they'll get fined again. Hardly surprising from a company based in a country that bombs children with support based in a country where they simply don't do that sort of thing...
I hope you get access to your data. If you have such strong political aversions to U.S. based companies perhaps you should look elsewhere for your technology needs. I'm sure you wouldn't want to compromise your principles.
I personally have not had any trouble with MFA or accessing my data on SharePoint... either on my own projects or concerning the companies I contract with.
@@advantageapplications5712 Those are not strong opinions, just observations. America has killed more people since WWII than the nazis. What its doing in Palestine is obscene, the act of a very sick people. But I guess you guys would rather spend your money bombing children than having things like free healthcare or a better standard of living, maybe even tidy up your streets a bit... Seriously, you could have had free healthcare for all for less than you spend on genocide... The world is done with it. As for Microsoft etc. I'd ditch them in a heartbeat, in fact I only use MS products because clients do.
I took a college class on this, but I dropped it on the last day I could get the refund. It warms my heart that I chose the rightclass to drop.
Yeah? What do you do now?
Still more viable than Salesforce.
Ha... true!
No.
Actually, when Access is linked to data on SharePoint most of its limitations are completely overcome. And it's much easier to build powerful apps in Access than even modern, so-called "no code" / "low code" environments. And, since the data is on SharePoint, you can leverage and integrate other tools and technologies like Flow, Power BI, and Power Apps.
My upcoming videos are going to take deeper dive into those very topics. I hope you can stick around and check them out.
@@advantageapplications5712can’t wait to see them! New sub here🎉
Still lol, was it ever?
My experience is that folks who say that about Access don't know anything about it.