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

4 ай бұрын

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!

@davegoodo3603

4 ай бұрын

@@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

4 ай бұрын

Oracle and SQL Server are database servers, MSAccess is a file server. They are different server types

@Albertkallal

4 ай бұрын

​@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.

@charlesbaldo

4 ай бұрын

@@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

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

@advantageapplications5712

3 ай бұрын

That is solid advice for sure. Thanks for checking out my video!!

This is exactly what I have been searching for! Thank you so much!

@advantageapplications5712

4 ай бұрын

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!

@alanhunold7546

4 ай бұрын

@@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

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.

@advantageapplications5712

3 ай бұрын

Yes, absolutely, that is awesome. I need to do a video on that as well. Thanks for checking out my video!

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.

@Albertkallal

4 ай бұрын

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.

@advantageapplications5712

4 ай бұрын

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.

@zincfive

3 ай бұрын

​@@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.

This is going to be exciting. Thanks for sharing

@advantageapplications5712

3 ай бұрын

Thanks so much for the positive feedback!!

Excellent tutorial about Access. Thanks for sharing👍❤

@advantageapplications5712

4 ай бұрын

Thank you for that kind feedback, and thanks for watching!

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.

@advantageapplications5712

4 ай бұрын

That's an awesome pro tip, thank you for sharing it!!

@zincfive

3 ай бұрын

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...

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!

@advantageapplications5712

21 күн бұрын

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.

Another Excellent tutorial. All thumbs up Rick, already subscribed. Thank you so much for your time to prepare this valuable info

@advantageapplications5712

4 ай бұрын

Thank you for that very kind feedback, Jojo! Very much appreciated my friend.

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.

@advantageapplications5712

3 ай бұрын

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.

This was excellent!!! thank you

@advantageapplications5712

3 ай бұрын

Thanks for watching my video and for that very kind feedback!

I use it to prototype....excellent for smaller rapid dB apps.

@advantageapplications5712

3 ай бұрын

Yes, totally agree.

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.

@advantageapplications5712

4 ай бұрын

Hi Charles, well said, sir.

Well done, Sir!

@advantageapplications5712

Ай бұрын

Thanks! And thank you for watching!

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.

@advantageapplications5712

4 ай бұрын

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!

@zincfive

3 ай бұрын

@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)

Brand new to Access, looking to apply it to project management applications.

@advantageapplications5712

2 ай бұрын

I think that could be a very good fit!

@TheBlueHutch

2 ай бұрын

@@advantageapplications5712 thanks so much ☺️

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.

@advantageapplications5712

4 ай бұрын

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!

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.

@advantageapplications5712

2 ай бұрын

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!

my last time was 2008, thanks for the heads up (Breaking Bad too)😄

@advantageapplications5712

3 ай бұрын

lol... thanks for checking it out!

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.

@Albertkallal

3 ай бұрын

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.

@advantageapplications5712

3 ай бұрын

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?

@Albertkallal

3 ай бұрын

​@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

Nice anyalisis!👍

@advantageapplications5712

4 ай бұрын

Thank you my friend!

😅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

@advantageapplications5712

3 ай бұрын

Hey! Thanks for watching and commenting... that sounds like a perfect use-case for Access tied to SQL Server. Spot on.

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?

@advantageapplications5712

4 ай бұрын

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!

@Albertkallal

4 ай бұрын

@@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........ kzread.info/dash/bejne/ZauYzLuCktzFkpM.html

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.

@advantageapplications5712

4 ай бұрын

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!

@FilipCordas

4 ай бұрын

@@advantageapplications5712 Great video by the way.

@phillic004

2 ай бұрын

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.

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.

@advantageapplications5712

4 ай бұрын

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.

@davidcochrane1888

4 ай бұрын

@@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.

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?

@advantageapplications5712

4 ай бұрын

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!

Active directory ... to record a person using AdB or chose from to put in record?

@advantageapplications5712

4 ай бұрын

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.

@Rok_Piletic

4 ай бұрын

@@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

I always thought the Access database builders and wizards were simpleminded when compared to Visual FoxPro (or dBase) database wizards and builders.

@advantageapplications5712

3 ай бұрын

How so?

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.

@advantageapplications5712

4 ай бұрын

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.

@danny1103

4 ай бұрын

​@@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.

@Albertkallal

4 ай бұрын

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.

can we say access front end, sql back end good idea for mid or big size business?

@advantageapplications5712

4 ай бұрын

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.

@adobestock7048

4 ай бұрын

@@advantageapplications5712 Great tips from you, thanks a lot.

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

4 ай бұрын

ask me how I know lol

@advantageapplications5712

4 ай бұрын

@@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.

Access is great for showing a proof of concept. Afterwards, hire developers to make the “real” application.

@advantageapplications5712

3 ай бұрын

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". ;)

Today I see it has a ODBC client to Oracle.

@advantageapplications5712

3 ай бұрын

Yes, definitely.

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 😅

@advantageapplications5712

4 ай бұрын

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.

@Albertkallal

4 ай бұрын

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.

Now, it is preferable to turn to a web interface with a language like php or asp It is much more universal

@advantageapplications5712

4 ай бұрын

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.

@bipbipcoyote5520

4 ай бұрын

@@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

yes it is

@advantageapplications5712

4 ай бұрын

Couldn't agree more Juan! Thanks for the feedback my friend.

@juancampos1164

4 ай бұрын

Here's a VERY good reason, lets say the database needs to be worked where there is no internet. @@advantageapplications5712

It will never replace Visual Foxpro, which will never replace Foxpro OG...

@advantageapplications5712

3 ай бұрын

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!

Access is the best.

@advantageapplications5712

4 ай бұрын

It certainly is under rated and often overlooked entirely. Thanks for watching my video!

I loved MSACCESS but unlike EXCEL every new step forward created problems with backwards compatibility, eventually gave up and used other products.

@advantageapplications5712

3 ай бұрын

Oh yeah? I hate to hear that. What did you ultimately wind up using?

@ianbirkinhead4103

3 ай бұрын

@@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.

Sharepoint list is no good for thousands of records though, at least that's what I found. Far too slow.

@advantageapplications5712

4 ай бұрын

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.

@RichardJones73

4 ай бұрын

@@advantageapplications5712 yes I think that's a fair comment.

@zincfive

3 ай бұрын

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 can’t imagine Hector Salamanca working many overtime hours.

@advantageapplications5712

3 ай бұрын

;)

Isn't Access really just a desktop database app? It's certainly useful for that. But if you're talking about a website or something, it's not really designed for that sort of thing.

@advantageapplications5712

4 ай бұрын

Hey! Yes and no... the original intent of Access was to serve as a Desktop DB. BUT, because it's so adept at connecting to server-based data soruces (SQL Server and SharePoint in particular), it becomes a lot more powerful. Add to that the fact that you can extend its capabilities using PowerApps, Power Automate, and Power BI AND the fine degree of control you have over customization and automation using VBA and you have a really powerful tool for creating custom solutions intended for "real" work. Web pages, it still isn't good for.

@FreeEasyAI

4 ай бұрын

@@advantageapplications5712 Yes, that's what I meant. It's a desktop database use it at home myself for stuff that doesn't ever need to be public or large-scale. There are many use-cases for such a database.

MS Access is too limited. And macros makes it a nightmare to deploy among multiple machines. It taught me a lot though.

@advantageapplications5712

3 ай бұрын

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!

@zincfive

3 ай бұрын

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

@ad7711x

3 ай бұрын

@@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.

@zincfive

3 ай бұрын

@@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.

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...

@advantageapplications5712

4 ай бұрын

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.

@m12652

4 ай бұрын

@@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 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

@advantageapplications5712

3 ай бұрын

Well, I certainly can't argue with you there, my friend. Someone once said Microsoft advances by revolution instead of evolution.

Still more viable than Salesforce.

@advantageapplications5712

4 ай бұрын

Ha... true!

Still lol, was it ever?

@advantageapplications5712

4 ай бұрын

My experience is that folks who say that about Access don't know anything about it.

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.

@advantageapplications5712

3 ай бұрын

Yeah? What do you do now?

No.

@advantageapplications5712

4 ай бұрын

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.

@dwang085

4 ай бұрын

@@advantageapplications5712can’t wait to see them! New sub here🎉

I'm endeavoring to construct a database using intricate Excel files. Since I'm starting from the ground up, any assistance would be greatly appreciated. We operate as a small business unit comprising four users, yet the data serves various functions across the company. Please inform me if you can offer guidance in the right direction. Eagerly awaiting your ideas.

@advantageapplications5712

4 ай бұрын

Hi Niggszo, and thanks for checking out my video! Quick question, would you be using the Desktop version of Excel or the online version?

@niggszo

4 ай бұрын

@@advantageapplications5712 thanks for your quick response, we are currently using the 365 desktop version.

@zincfive

3 ай бұрын

Quick question, long answer... There can be a fair amount to that. Firstly, understand that your tables in excel are the same as tables in any database. The important magic when you get to a proper database is "the relational database management system. (RDBMS)" These are statements that link the data from one table to another. For instance a Primary Key is a column in a table that is unique for any line. It could be as simple as line1, line2, line3. The next thing is Foreign Keys and their properties, for instance if you have a table of employees and a table of jobs, you have a column called JobID (sales, manager, production), and link to the table Jobs to the unique JobID and you then dictate what happens if you change the name of the primary key or delete a line. Those are called "Constraints" Read up on the relational model, creating a RDBMS from Excel, things like that, and they try putting an example set of your data in place, figure how to make a form with that data and step through it, edit it, etc, and learn from there. Good Luck!