September 21, 2012 at 11:49 am
Brandie Tarvin (9/21/2012)
Ray K (9/21/2012)
pvanitallie (9/20/2012)
I have been looking for something in a Visual Studio-type product as a way to convert an existing MS Access Front End to a SQL Server back end with nearly 10 users on multiple sites.I like the rapid application development tools that Access provides and can still be used by people who are using Office 2003. But the world is changing. A Web front end is going to provide a more uniform response time and no need to update the front end at each work site. I expect to use SharePoint to do the authentication that is provided by Active Directory (so that the application does not have to authenticate users).
I have not been able to find a set of tools that will let me have the forms with drop down boxes, command buttons, text displays and waterfall displays that are easily added and customized for Access. But I have not found anything suitable in my search so far; I have experience using Visual Studio. I've tried several ASP.NET tutorials and usually can make them function but cannot find a way to mimic the simple functionality of MS Access to display, update and add to the data in a SQL Server database.
What do you recommend?
IMHO (and to anyone who reads this who knows anything different, please feel free to correct me), you're already there. You're not going to find anything else.
I don't know. Doesn't Visual Studio have those tools? Our devs use it all the time to work on our Access .adp file. They code using VB script, VB.NET, and C#.NET.
Yes, that is true, but if I understand his point correctly, he's looking for a do-it-yourself tool to build the interface in a WYSIWYG style. VS would still require you to do some coding.
Am I interpreting that correctly?
+--------------------------------------------------------------------------------------+
Check out my blog at https://pianorayk.wordpress.com/
September 26, 2012 at 5:45 am
As the OP its comforting to know the topic is still alive!
Can anyone comment on the Web options in Access 2010?
Allen
September 26, 2012 at 8:06 am
Thanks for the thoughts and suggestions.
Think of the question as asked by a neanderthal.
My problem is that Visual Studio 2010 seems overwhelming. Where and how does one begin? The "tool bar" in Visual Studio has grown from when I first used VS 2005. In Visual Studio 2010, the tool bar is extremely large. The tool bar is confusing. There are two different "data" tabs.
I was hoping for a easier way -- a road map -- that would allow similar drag and drop to make functions that would mimic the modest set of options that MS Access offers. A barely functional, hard to use Web form has Scrips folders and Styles folders, dot asp, dot config, dot sitemap and dot master file types. Yes, I would like a way to simply convert each of the MS Access forms into something that worked in a similar fashion as a web page. (Dreaming).
With MS Access there are only six types of objects (tables, queries, forms, reports, macros and modules). To make a form for the web, complexity has increased and web pages are more difficult to maintain. Debugging someone else's design seems to harder than in MS Access.
I would like a pointer to a guideline for a programmer's first steps -- not to programming and not necessarily to user interface design but to functionality. Would it be better to ask if there is a "user manual" to change thinking from the pre-Web dark ages?
September 26, 2012 at 8:20 am
pvanitallie (9/26/2012)
I would like a pointer to a guideline for a programmer's first steps -- not to programming and not necessarily to user interface design but to functionality. Would it be better to ask if there is a "user manual" to change thinking from the pre-Web dark ages?
I'll admit that I work with VS2010 on a daily basis, so I'm biased, and I probably take a lot of it for granted.
Having said that . . . my first question off the bat is, how familiar are you with structured and/or object-oriented programming? If you have a structured programming background, then as long as you understand the concept of objects, you should be able to pick up OOP pretty quickly.
I often refer (and bookmark) online programming references, mainly MSDN. There are a number of others out there, but I can't think of them off the top of my head; if I think about it later, I'll make sure I post some links.
Everything is overwhelming when you're first starting out -- I can tell you from experience that I was pretty overwhelmed when I first started using VS. Best advice I can give is to take your time, don't try to learn everything all at once (it never happens), and take the time to "play" with the system and get familiar with it (in a safe environment, of course).
Hope that helps . . .
+--------------------------------------------------------------------------------------+
Check out my blog at https://pianorayk.wordpress.com/
September 26, 2012 at 8:27 am
Let me say one more thing: what you're experiencing reminds me of what happened to me. I was in a nearly identical boat: I was working with Access, was trying to transition to SQL Server, and was looking for a way to easily build a front-end much in the same way as Access. I found that it couldn't be done, and concluded that I pretty much had to roll my own.
I think that was about ten years ago. The rest is history.
So, I've been in your shoes before. Just be patient and take it a step at a time. Speaking as someone who's been there, you'll get there.
+--------------------------------------------------------------------------------------+
Check out my blog at https://pianorayk.wordpress.com/
September 26, 2012 at 8:58 am
Thank you, Ray.
I have a small bundle of SSRS reports and SSMS stored procedures that I have written and are still in use, all using other people's front ends.
Now I am trying to replicate the functionality of a modest Access application on the Web. SharePoint does not have the ability to share (dare I say that?) MSSS databases but has to have its own EXCLUSIVE database.
ASP.Net seemed to be an appropriate base but none of the samples on Microsoft sites seemed to be have the command buttons to navigate to screens (forms) that would allow end users to read, update or add new records containing joined records.
I'm sure that the view after a few months of productive development will make these initial steps seem trivial. Thanks for your encouragement.
September 26, 2012 at 11:18 am
Now I really _do_ feel like a Luddite.
September 26, 2012 at 12:35 pm
pvanitallie (9/26/2012)
Thank you, Ray.I have a small bundle of SSRS reports and SSMS stored procedures that I have written and are still in use, all using other people's front ends.
Now I am trying to replicate the functionality of a modest Access application on the Web. SharePoint does not have the ability to share (dare I say that?) MSSS databases but has to have its own EXCLUSIVE database.
ASP.Net seemed to be an appropriate base but none of the samples on Microsoft sites seemed to be have the command buttons to navigate to screens (forms) that would allow end users to read, update or add new records containing joined records.
I'm sure that the view after a few months of productive development will make these initial steps seem trivial. Thanks for your encouragement.
My pleasure. 🙂
ASP.NET is actually very appropriate. Where you might be running into a roadblock (and I apologize if I'm insulting your intelligence here; I don't know your experience, so I can't assume) is knowing the difference between client and server. The compiled ASP.NET back-end code lives on the server; it sounds like the functionality that you're looking for (forms, screens, navigation, etc.) lives on the client side. Knowing the difference between front-end client and back-end server is key; you'll be able to effectively leverage your code, and when you're looking stuff up on MSDN or Google, you'll know where to look!
And once you've mastered it, you'll have a powerful development tool at your hands -- not to mention something good to put on your resume. 😉
+--------------------------------------------------------------------------------------+
Check out my blog at https://pianorayk.wordpress.com/
September 26, 2012 at 2:18 pm
Dumb beginner question:
Let's start with whatever is equivalent to a MS Access "form" which is the first screen that the user sees. I describe an existing Access 5-control button main menu. The menu screen (first screen after authentication) has no data to display -- just a few command buttons (and later, a possible drop down selector based on the user's permission to look at different data groupings):
Entry (to allow review/update or add new data)
Mgmt (to find specific prior entry)
Reports (to select a report)
Maintenance (to review/update or add new records to control fields)
Exit
Subsequent "screens" will have either more buttons to select details or will display data.
So what is this starting point for this five command button screen? Is is a "Web page", a master page or ?
September 27, 2012 at 6:42 am
pvanitallie (9/26/2012)
Dumb beginner question:Let's start with whatever is equivalent to a MS Access "form" which is the first screen that the user sees. I describe an existing Access 5-control button main menu. The menu screen (first screen after authentication) has no data to display -- just a few command buttons (and later, a possible drop down selector based on the user's permission to look at different data groupings):
Entry (to allow review/update or add new data)
Mgmt (to find specific prior entry)
Reports (to select a report)
Maintenance (to review/update or add new records to control fields)
Exit
Subsequent "screens" will have either more buttons to select details or will display data.
So what is this starting point for this five command button screen? Is is a "Web page", a master page or ?
Your front-end button screen can be built as a web page using plain old HTML. That would be the client side.
However, if you want it to access and manipulate data, you'll need to set up some kind of back-end server functionality.
There are probably dozens of different ways you could set this up. You can use a web form submit, you can use ASP.NET, JQuery, MVC, AJAX, etc. However, no matter the technology, they all maintain the same basic principle: you're taking a front-end form (your client side) and you're using it to talk to some kind of functionality that does the work and stores your data (your server side).
Here's another question: does your application have to be web-based? Because if it doesn't, you can take your existing Access application and use it strictly as a front-end interface to access your SQL back-end data. In other words, your Access app is not storing any data in and of itself; it is only being used as a form for your data.
Does this make any sense?
+--------------------------------------------------------------------------------------+
Check out my blog at https://pianorayk.wordpress.com/
September 27, 2012 at 7:31 am
Thank you!
My Access application has been migrated from a all MS Access to an Access front-end and a SQL Server back-end for a little over a year. There are five copies of the front-end, on servers at each office location.
The reasons for changing to or offering a Web front end are (1) so that employees can access the application from anyplace, (2) improved performance and (3) as a way to learn how to put an application on the Web. There is a possibility (4) that users on tablets and smart phones could use the application in the future. I think that the intent is to have BOTH a Web and an MS Access front end to the same SQL Server database. All data is in the SQL Server database. The front-end does not have any local tables.
I am confused about the way that you separate client and server. I thought that ALL of the function would be at the server and that the Web-front end was just a collection of code that presented the data to the user. When the user typed or selected, the Web application (code in HTML or VB or C or Java or ...) would perform the appropriate validation and provide data to the user or accept data from the user and make the updates to the (SQL) server. I view the Web front-end as a client resident on a server with fast access to the SQL server data repository. The Web approach eliminates the need for MS Office on the user's machine and allows the possibility of smart phone or tablet users to have full use of the application.
And I am still unclear about which Visual Studio piece that I should select as the place to put the command buttons, text boxes, drop down boxes.
September 27, 2012 at 8:12 am
pvanitallie (9/27/2012)
The reasons for changing to or offering a Web front end are (1) so that employees can access the application from anyplace, (2) improved performance and (3) as a way to learn how to put an application on the Web. There is a possibility (4) that users on tablets and smart phones could use the application in the future. I think that the intent is to have BOTH a Web and an MS Access front end to the same SQL Server database. All data is in the SQL Server database. The front-end does not have any local tables.
Ah, okay. That makes sense. I assume you're trying to set this up on an intranet? I remember you mentioned something about Sharepoint. We have a Sharepoint setup here as well, but I'm not responsible for it, I really don't use it for anything other than documentation and posting useful links for my team, and I've found that it's not very intuitive and can be frustrating to use.
You can easily set up some kind of intranet environment to do what you need.
I am confused about the way that you separate client and server. I thought that ALL of the function would be at the server and that the Web-front end was just a collection of code that presented the data to the user. When the user typed or selected, the Web application (code in HTML or VB or C or Java or ...) would perform the appropriate validation and provide data to the user or accept data from the user and make the updates to the (SQL) server. I view the Web front-end as a client resident on a server with fast access to the SQL server data repository. The Web approach eliminates the need for MS Office on the user's machine and allows the possibility of smart phone or tablet users to have full use of the application.
And I am still unclear about which Visual Studio piece that I should select as the place to put the command buttons, text boxes, drop down boxes.
Hmmm, well, a full discussion of this goes beyond the scope of what I can post here (in both space and amount of time I have). So, in lieu of that, I'll just post a quick primer.
Yes, it is true that pretty much all web files reside on the same physical location. What happens (and I hope I explain this correctly) is that a web client (let's say the web browser on your laptop) grabs a copy of the HTML for itself and works off that. That is your cached copy.
The front-end web client and the back-end web server is more a virtual, rather than a physical, concept. However, it's very important to distinguish the two because neither side knows the other exists. You cannot view server-side code from client-side HTML (which is especially good for security reasons), and the server-side code doesn't know about the client, unless the client asks it for information.
Try this: draw two separate boxes (almost like a Venn diagram). Label one "client" and label one "server." The client is your workstation; the server is self-explanatory. Your front-end web stuff that you see (like your forms) is in the client. Your database and code that performs various functions is in the server.
There are a few sites that explain these concepts. One of my personal favorites is 4 Guys From Rolla. If I can think of any more (and I have time to do so), I'll post them.
Would love to keep talking about this more, but lack of time is keeping me from doing so (I do have my own work to do, after all), but I'll post more later if I have a chance to do so.
+--------------------------------------------------------------------------------------+
Check out my blog at https://pianorayk.wordpress.com/
September 28, 2012 at 12:44 pm
Thanks Ray.
I took a look at the 4GuysFromRolla and found a promising article on making your first web page (Chapter 3). The article states, that it uses the Web Matrix Project to create ASP.NET pages.
REF: <http://www.4guysfromrolla.com/webtech/chapters/tyaspnet24hrs/ch03.pdf>
Unfortunately, the material presumes that you are using Web Matrix (a free alternative to Visual Studio in 2005) and I can not find a copy of either the original or the re-released Web Matrix. I'm going to try to guess what to use in Visual Studio 2010 starting with a Blank Web Page on an existing project that uses localhost.
September 28, 2012 at 1:03 pm
pvanitallie (9/28/2012)
Thanks Ray.I took a look at the 4GuysFromRolla and found a promising article on making your first web page (Chapter 3). The article states, that it uses the Web Matrix Project to create ASP.NET pages.
REF: <http://www.4guysfromrolla.com/webtech/chapters/tyaspnet24hrs/ch03.pdf>
Unfortunately, the material presumes that you are using Web Matrix (a free alternative to Visual Studio in 2005) and I can not find a copy of either the original or the re-released Web Matrix. I'm going to try to guess what to use in Visual Studio 2010 starting with a Blank Web Page on an existing project that uses localhost.
Sounds like a plan. Again, if I have time to post more (not right now), I will do so.
Good luck.
+--------------------------------------------------------------------------------------+
Check out my blog at https://pianorayk.wordpress.com/
September 28, 2012 at 1:11 pm
Thanks for the encouragement.
I had a problem. Whenever I've tried to use a project that specifies localhost, I get
Service Unavailable
HTTP Error 503. The service is unavailable.
I will try to do this again with a different, non localhost project.
Viewing 15 posts - 16 through 30 (of 33 total)
You must be logged in to reply to this topic. Login to reply