Can anyone recommend the best web-based technology/language for rewriting a ms-access front-end? I've already converted the tables to MySql and moved all the queries into stored-procedures. The language will need to be able to handle multiple result sets.
Also, I need the GUI to be as similar as possible to the current ms-access front-end. So the new language will need to have features including full CRUD, tabbed forms, datasheet style sub-forms, combo-boxes and reports.
I've dabbled a bit with html, css, php, javascript and java but are any of these capable or suitable? I've heard that Ajax or jQuery might be the way to go.
This is a misguided goal.
Web UI uses completely different paradigms because a web front end is stateless, with unbound data, whereas Access apps are stateful and bound. A 1:1 translation will be a disastrous way to implement a UI in the web browser, unless you invest a HUGE amount in AJAX development.
That said, you should look into Access 2010 and Sharepoint Access Services, which allow you to createn Access front end with web forms and web reports that can be run in the web browser unchanged. This would likely be an order of magnitude cheaper than rolling your own AJAX-based replacement.
We are in the process of doing this. In order to keep the "spreadsheet-style forms" that we have with Access, and which include ordering and filtering capabilities as standard on all screens, we took the decision to go for silverlight + Infragistic toolkit on top of it. Up to now, we have already developped a few screens with these tools, and are quite satisfied with the result.
Related
We have some JSP code to run in our pages.
There is a UI designer who will constantly update the UI but does not have Tomcat server. We prefer he doesn't because he isn't a programmer.
However, it is getting annoying to have to cut and paste the JSP related code each time he updates the UI.
Is there anyway to handle this issue? We prefer to keep the same files, but still have it so he can see his UI work without worrying about the JSP and when he checks in the new files, we don't have to cut and paste our JSP related code.
One example of such code, is that there are certain navigation menu items which are displayed depending on the user.
We are using Tomcat authentication. We could I suppose use AJAX to obtain the user information, but is that less secure? Everything else in the application is AJAX.
The problem here is that this person is not working with the team. Rather, he's creating work for them... and it goes both ways. Read on.
I both do and manage front end development. If this UI person was on my team, I would force him to set up a Tomcat server. He just needs to learn some things.
In effect, when implemented properly, JSP is not much different from any other server-side markup language for views, such as Rails + ERB, PHP, .NET etc... even Javascript templating engines (mustache, handlebars, etc.). The same condition checks, for-loops, auth checks - all basic view-layer logic that is needed is available and usable.
If he's on a Java project / team, he needs to learn the Java front-end. It's that simple.
His main tasks should be basic, and frankly, he shouldn't even need to install a Java IDE to do them. They are:
Get/push source code + analyze diffs (any source control client)
Build / deploy latest to his local environment (scripts or .bat files)
Work on the running app*
(*) The last part is where things get tricky. If you work directly on the running server and then accidentally run a fresh deploy before copying over your updates, you're screwed. If you use symlinks (which are also available in Windows), there may be files that only appear post-compilation, or locks, or sync issues when getting latest code - all creating problems.
The way I have found that works best is to work on the code repo location (pre-build), and create two scripts:
Build+deploy - stops running server, blows out directories and caches, builds latest, and redploys
Update - Synchronizes the View files and any other necessary directories with the deployment target. You must be sure to disable hot-deploy in the Tomcat config, or you'll get memory leak errors.
That said, and it should be obvious by now: Java is one of the most difficult ecosystems to develop UI's for. The compiled nature and complex environment requirements make development slow and tedious, with significant dependencies on different people or systems to make a decent product.
JSP itself, while capable as described above, is almost always organized badly, with various ways of includes, tagfiles, partials, frameworks - it becomes a UI person's worst nightmare. GSP (from Grails) solves a lot of the organizational issues, but will require flexibility from the dev team. Even then it is not an "ideal" solution.
JSP syntax - JSTL, C:tags, etc. creates even greater headaches. Front-end people who do not program, don't use IDE's and therefore don't have a way of looking up methods, objects, parameters etc. when writing or customizing conditional logic or loops. The dev team can help by pre-writing these out on the page, but any time there are changes or enhancements needed, it requires meetings, conversations, and compromise.
In the long run, you should abstract the Java app from a separate, more flexible, more capable front-end technology stack, using REST / JSON-based services to talk between the two. (Side note: For performance / apps with scale, ensure you are using either a custom protocol or Web Sockets).
My preference is node.js, because front-end developers can stick with the language they will know best: Javascript / JSON. But it could be anything that your particular front-enders are comfortable with and can do design with.
The key is to eliminate bottlenecks on both front-end and back end. Both tracks should be able to develop and iterate quickly, with the RESTFUL API being the key point of collaboration.
Lastly, for those of you who are aspiring front-end developers / designers but only know Java (or some other server-side technology), I CHALLENGE YOU to learn something new. User-facing technologies are in a constant state of change, and more recently that change has accelerated. If you want to have UI-competitive products, you need to invest in technologies that will make them competitive.
We have developed a standalone application using visual basic 6.
Now we are changing the standalone application to web application.
Is there any way to convert VB6 forms into plain HTML forms so that my work will be reduced alot.
please give your suggestions.
Edit: I am new to VB6 and .net technology
Don't even think about "converting". It's not just a "conversion" process. The entire paradigm is different between web applications and desktop applications. They're just totally different.
ASP.NET web forms try to make the differences less apparent. However, the differences are still there, and are still huge.
What you should do is separate your business logic from your forms logic in your VB6 application. You will then be more easily able to convert the business logic into .NET business logic. You'll still need to create equivalent forms, but the logic will be the same.
You cannot simply convert VB6 form to html, there is some website which provides this conversion.. but this will increase your work more
refer - VB to HTML convertor
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I'm a Java EE developer and was just contacted by someone who wants me to put a quote together for an application for his business that can integrate with their MS Access "backend".
I was hoping to post this and just get a general high-level overview of best practices involved with MS Access Programming. I assume the program would be entirely in VB, but didn't know if I would have the option of writing something in VB.NET or (preferably) C#.
Also, I despise the presentation layer: any good GUI-builders for Access applications?
What are some common tools and APIs (unit test frameworks, build automation systems, etc.) that MS Access programmers frequently use?
Any links or resources you would recommend?
It sounds like a pretty simple application: take inputted data, compare it to some tables, and throw some output to the screen. I'm a pretty decent programmer so even though I've never done an Access program before it couldn't be too difficult for me to pick up.
Thanks for any thoughts or suggestions!
Access as a front-end
Well, people feel strongly about Access. The main reason for the negative view is that it is widely used by non developers who have no concept of proper database development and end-up with these barely working, horribly designed applications that bring dread into the heart of developers.
Having said that, Access is nothing more than a Rapid Application Development tool with a very low barrier of entry.
The good and the bad
Access is a fairly old product line, spanning almost 20 years. A lot of people's objections to Access as a technology are grounded in its early history: since backward compatibility is something that Microsoft deems important, Access has retained most of its features, good or bad, over the years.
You can see the choice of VBA, non-winform forms, promotion of modules over OOP, to be bad choices, but the continuity of these early-on design decisions have made Access a stable platform to build on.
VBA: is the language that never dies. It's clunky, outdated, lacks recent advances in languages, but it's also fast, simple to learn, flexible, easy to interop with (for instance calling Win32 APIs is really simple), and it can be interfaced with external libraries (event written in .Net).
Bound forms: by default Access makes it easy to create working applications without a line of code. Most queries can also be created without having to go down to SQL at all. If you're a control freak, it can be annoying, but it's easy to drop down to code and control everything from there.
Third-party integration: even though there are lots of add-ons to Access, I wouldn't recommend using most of the user-controls or third-party libraries unless you really have to. They can be very hard to deploy in environment with limited user rights and versioning can become hairy.
Ribbon: it may be good or bad, depending on who you talk to, but Microsoft has invested a lot into it and it'll probably be there for a while. At least the Ribbon and the improved controls in Access 2007 and later make applications look and behave in a modern way. Gone the horrible UIs of old, you can now do really pretty things with themes, HTML layouts and a modern ribbon.
Reliability
Most of the objections, especially about reliability, are simply no longer true.
A carefully designed Access Application can support dozens of concurrent users. I have a decent-size application managing Procurement/Stock/Quality/Parts/Projects for a manufacturing company that has 150 users, of which usually 50 are connected at any given time. I haven't had any corruption in years.
Of course, you must always bear in mind that Access is a multi-user file-based database, so you cannot expect it to work without risk in environments with unreliable or slow networks, and connecting to a an Access backend through WiFi is really asking for trouble, just like you wouldn't work on large Excel file over wireless either.
Maintenance is part of the lifecycle of an application. Preventive maintenance is extremely important.
Don't wait for something to go wrong: build some admin tools within your app that will help check the state of your data (make sure everything is coherent, detect invalid user inputs, etc).
Also compact the database regularly (I do it nightly after I make a backup as part of the daily automated tasks on the backend server).
Some random tips
Make sure your front-end and back-end are split: only data should be on the backend, and the front end should be installed on each user's machine.
From your front-end, open a permanent link to a dummy table on the database back-end: keeping an always-on connection will greatly improve performance. For the reason why, have a look at this question.
The backend should be in a shallow network share (don't put it deep under multiple directories).
Make sure you think hard about how you will deploy your updates to all clients automatically.
There are many ways to do this. I developed my own but you could use ClickOnce or Tony Toews's Auto-Front-End Updater
Use the Runtime: your front-end application can run without users meddling with its internals if you deploy the Access Runtime on their machine. It's free too.
Don't fight the tool: Access has a certain way of doing things. Just use the tools available without going to code until you have exhausted the capabilities of the RAD environment. You may be surprised by how much you can achieve without any code at all.
Nothing stops you from using OOP: defining classes and binding your classes manually to your forms, controlling data updates, etc. The default behaviour in Access tends to encourage quick-development and is fine for small projects, but if you suspect that your project might grow, plan for the future, just like you would with any other framework.
Access as a backend database
Now, if you want to use a front-end written in something else, say C#, it's fairly easy to use Jet/ACE drivers to connect to an Access back-end database.
Jet is the older driver for Access and only supports .mdb files. 32 bits drivers are installed by default in Windows (still there in Win8) and can always be relied upon.
ACE is the new .accdb format used by Access2007/2010/2013. It has increased limits and enhancements over the older version but it can still talk to an .mdb.
You will have to install the Microsoft Database Engine on all the clients (not necessary if either a full version or the Runtime of Access 2007/2010/2013 is already installed though).
Don't try to use 64bit versions of Access/ACE driver. It's the future but it introduces many new issues, especially if you are using 3rd-party libraries or some of your clients have 32bit Office installed (your can't mix and match 32bit and 64 bit office components).
Similarly, don't build your C++/C#/Java/Python front-end app in 64bit mode and expect the 32 bit ACE driver to work. Keep everything in 32 bit, make things work, then test 64 bits versions if you really need to.
Do always keep at least a single connection open to the back-end database from your code, as mentioned above.
Ideally, try to abstract any Access-specific code to make it easier later in case you need to switch to a server-based database. You could use an ORM that can talk to different back-ends transparently, or you could at least separate your SQL queries into resource files or separate objects that can be easily replaced later.
Depending on the load (mostly how much data need to be changed in the DB), an Access back-end can easily accommodate between 20-100 users without issues. Things will deteriorate if there are lots of insert and updates occurring all the time. There are lots of tricks that can be used to make things better and make Access scale well, but you are inherently limited by the type of application your are building and how users are accessing its data.
I was wondering what the advantages/disadvantages of using Microsoft Access would be compared to just creating a custom C# application. Is the execution time the same? Has its time already passed?
C# is a generic development environment designed for producing all applications that can be conceived of.
Access is a development tool specifically designed for one purpose, i.e., creating front ends to databases.
All the components within Access are prebuilt to make interaction with data as easy as possible.
While it is certainly the case that there are libraries and controls available for C# that are designed for the purpose of interacting with databases, there's less integration of the overall development environment for the particular purpose of creating database applications.
Access's database-related components are also more mature than anything that could be developed for C#, since Access has been around twice as long. That also has its disadvantage, as some of the assumptions about how things should work in Access don't work as well in a modern environment (Access was created before the web existed anywhere outside of academia).
I think it's probably OK to choose C# as a development platform for a database application if:
the developers available are already C# whizzes familiar with building database interfaces, AND
you have the need to distribute your app to very large numbers of users.
Access is somewhat difficult to deploy, and in large organizations, when you amortize the savings in RAD over large numbers of desktops, that is quickly dwarfed by the expenses associated with Access deployment issues compared to a self-contained executable with no runtime dependencies.
But we're talking about somewhere well above 100 desktops where the line is crossed (and possibly closer to 500 or 1000), in my opinion.
Access has many plus points if you are dealing with data. One key point to make is to split in your head “Access” (RAD development studio where you make forms reports code etc) and “Jet” the database engine that in bundled with Access.
Access makes a great front end of other database types such as SQL server and you can very quickly make excellent data driven applications very quickly.
You also have an excellent built in reporting suite and easy access to other MS Office applications (sending mail through outlook for example)
Access has picked up somewhat of a bad reputation in IT circles as IT departments have been burnt before by having to support some badly put together application where the original “developer” has long since left. The point is that any language can be used to make a bad application but because more people have access to err access it increases the chances of someone who is not a developer making mistakes!
In my not so humble opinion, the big advantages of MS Access are the low learning curve and the the so much is already done for you. Simple apps can be built by an untrained clerical worker.
That's also one of the biggest disadvantages. MS Access applications are often first started by complete novices and they can get them selves into a lot of trouble. Quite often they get to the point that they are dependant on the app that has been built to do their job, but it needs to be expanded, or has become unmanageable because of some early "decisions" they made they they first started building it (e.g., using some human readable key to reference another table, with no integrity constraints, etc.; and now they have a lot more data than they started with).
Typically by the time that I see it, there's a lot of work to do to undo the previous "developer's" work. And sometimes it'll cost more in time to fix it, than to start over.
Left in the hands of a pro - it's fine for building quick simple apps. Even more complex ones are OK if a pro is doing it. If I had my way, we'd just hand out the runtime version and keep the full version to the IT Pros.
The advantages are the pre-built functionality along with the ability to write custom code when needed. Of course, all of this can be done in C#, it's just not as easy.
The biggest disadvantage to using Access is having at least one answer to every question on SO suggesting using something else. Or better yet, having someone knock Access eventhough they know nothing about it or haven't used it since 2.0.
The shop that I am working part time with is new to Microsoft CRM. I just want to survey what projects have developers done to the system to extend its capabilities.
I can break the work I did into four sections:
Tailoring - Simple field level changes. A lot of this is just making sure the fields and language suited the business I was developing for.
Customisation - More complex changes, generally needing JavaScript and maybe ASP.NET. Some examples would be to use an IFrame and pass values to it from a CRM form. The IFrame would then do interesting things like mapping, charting or give you buttons to do other things. For buttons I would often times use JavaScript to replace the outerHTML in the HTML dom of an IFRAME to show a button rather.
Integration - using .NET to connect MSCRM to other systems. Connected it to Great Plains, Speech Server, SCOM (was called MOM back then), custom LOB systems etc... One interesting one I did was to develop a SSIS component that wrote into MSCRM via the web services.
Reporting - Building reports. In reporting services and in Excel. Excel made for great dashboards because of the dynamic update nature of it.
I have a few (war) stories up at http://www.sadev.co.za/taxonomy/term/7 if you are interested.
I (and others) have implemented a LINQ query provider for the web service layer http://www.codeplex.com/LinqtoCRM.
I did some work with CRM 3.0. My work enhanced the program and turned it into a Document Management app, where you could scan and upload documents based on a case, contact, customer, vendor etc. The .NET SDK back then could have used a bit more work, but I hear with newer versions of CRM it has gotten better. CRM allows for attachments but not at all levels, more at the case level.
We extended 3.0 to send text messages rather than email. There are tools available (for 4.0 at least) to do that now, though.
We also extended it to push service appointments through to Exchange, as due to the workforce being mostly mobile they did not have the CRM client for Outlook.
Two other major areas of development not yet mentioned are plugins and custom workflow assemblies.
Plugins allow you to intercept many of the messages that CRM processes to insert custom logic. The possibilities this gives you are endless because you can intercept all kinds of messages including Create, Update, Delete, and even Read!
Custom workflow assemblies are assemblies that you register with CRM that integrate with CRM's workflow UI. Often times, they perform simple tasks that are useful when modifying form data. Other times, they are more complex like sending status reports.
Custom workflow assemblies are always listed beneath the native options. In the screenshot, everything below "Stop Workflow" was added via a custom workflow assembly.