How is Visual Studio as a database app development tool?

[keviny04]

I'm asking this because Visual Studio is free and Access is not, and free stuff always gets my attention . I've used Access for 20+ years, and have only had brief experience with Visual Studio and its variants (such as Visual Basic). My impression is that VS is an "all purpose" app development tool and may not as many features specifically made for databases as Access does. For instance, can I create and manipulate subforms in VS as efficiently as I can in Access? Does VS even have a subform control in form design (I didn't see it)? Does VS even have report design? Can I design complex database front-ends in VS? If I could make this work in VS, together with SQL Server, I could have an all-free solution for developing apps, which would be a game-changer for my home and business.

[ranman256]

I found that Access was easier and did everything for you. Instantly make a form bound to a table and all textboxes bound to fields.

Yet in VS, I had to manually do this, taking a lot more time. Yes, you dont need to purchase Access and neither do your users , a plus.
But I was able to develop 10 times faster in Access.

So its 1 of those personal choices: Light meat or dark, Republican or Democrat, Ginger or Mary Ann.

[keviny04]

I found that Access was easier and did everything for you. Instantly make a form bound to a table and all textboxes bound to fields.

Yet in VS, I had to manually do this, taking a lot more time. Yes, you dont need to purchase Access and neither do your users , a plus.
But I was able to develop 10 times faster in Access.

So its 1 of those personal choices: Light meat or dark, Republican or Democrat, Ginger or Mary Ann.

Yea, I figured it probably wouldn't be as straightforward as in Access, which is tailor-made for databases. For instance, in Access, when I have a subform datasheet with thousands of rows, Access would only retrieve data for the portion of the datasheet that is visible to the user at any given time, which helps performance. If the datasheet has 20 rows, Access only loads 20 rows (or so) of data until the user scrolls down the datasheet. Access inherently can do that without me having to do anything to make that happen. Can Visual Studio do anything like this, something we take for granted in Access? I would doubt that.

[CJ_London]

Why do you think VS is free? If you are developing apps for sale, you need a developer license.

Even if it is free, are you sure your clients will be happy paying and waiting for the significantly extended development time?

With regards access, where do you get the idea it only loads data a screenful at a time? It loads all the records but will display the first few when they are available.

And unless things have changed recently, VS does not support sub forms as you know them in access. Instead it has a data grid control

Don’t get me wrong, VS has it’s place, but it is not the same place as access.

[keviny04]

Why do you think VS is free? If you are developing apps for sale, you need a developer license.

Even if it is free, are you sure your clients will be happy paying and waiting for the significantly extended development time?

With regards access, where do you get the idea it only loads data a screenful at a time? It loads all the records but will display the first few when they are available.

And unless things have changed recently, VS does not support sub forms as you know them in access. Instead it has a data grid control

Don’t get me wrong, VS has it’s place, but it is not the same place as access.

I'm only interested in knowing the technical feasibility of VS as a database tool. All those side issues you brought up would have to be dealt with some other time.

Are you sure about the loading of all records? I opened up a table that had 600k rows and it opened up nearly instantly, and that was from a remote database on the Internet! Only when I started scrolling down the table did I see some sluggishness.

[CJ_London]

Are you sure about the loading of all records?

yes - all records meaning those defined by the recordsource. The reason for the sluggishness is due to you scrolling beyond what has already been loaded. As a simple test, ensure you can see the recordcount at the bottom - this does not get populated until all records have been loaded. One of the reasons you should not base forms on whole tables (unless there are only a few records).

When using a web based backend such as azure it is vital the developer takes on board the 'web way' - minimal data to be returned - which also has an impact on your azure (and other) licence which in part is calculated on the amount of data stored and in part on the volume of traffic in and out.

Be aware that the criteria parameter of the openform method is badly named, it is a filter, so all records will be loaded - but only the filtered ones are displayed. As a test, once loaded, click the filter button. All records per the recordsource will be displayed.

The workaround is to have a recordsource which returns an empty recordsource

SELECT * FROM myTable WHERE False


Then in either the form load event or form search criteria substitute False with your actual criteria. Plenty of examples of how to manage this on this and other forums