August 26, 2009 at 3:11 pm
I am curious as to what software others recommend for a front-end to SQL server. I currently use MS Access (2002 and 2007), but am interested to know if there is something better. (ie, more stable). I need something that can support fairly complex forms for data entry, and has good graphical reporting capabilities. My current frontends contain a LOT of VBA code.
[font="Comic Sans MS"]She Through Whom All Data Flows[/font]
August 26, 2009 at 3:51 pm
ASP.net, Winforms (VB/C#/etc)..
CEWII
August 27, 2009 at 4:25 am
Elliot has picked the obvious ones for you.
August 27, 2009 at 7:55 am
What I can go onto saying is pretty much anything BUT Access..
CEWII
August 27, 2009 at 10:40 am
Elliott W (8/27/2009)
What I can go onto saying is pretty much anything BUT Access..CEWII
assuming there is an Access ADP front end, what are your specific reasons...?
just being curious ..and happy to be educated.
________________________________________________________________
you can lead a user to data....but you cannot make them think
and remember....every day is a school day
August 27, 2009 at 11:31 am
Access wants you to go through its engine, even when you do pass-thru queries you are going through its engine. You lose a lot of control in the process. With any of the languages I mentioned you have a huge amount of control exactly how the data is accessed and how you want to do it.
Access was my first taste of databases 15 years ago. But it isn't an enterprise solution. If I purchased an app and found out is was running or backed by access I would be... displeased, there are much better ways. Quick and dirty, limited users, limited lifetime, maybe, I wouldn't do it, but I could see the justification. The problem is that when it starts it proliferates. IT won't give me what I want so I will build it myself, and then we start to depend on it and then somebody quits and nobody can change it or even maybe find it. Or we start making major business decisions on data that no one has any clue as to the quality of the data. I have seen all of these happen, and it is a hard habit to break. Just be thankful you haven't heard the phrase "excel databases". It makes a data guy woozy..
CEWII
August 27, 2009 at 2:54 pm
Best front end to do what?
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
August 28, 2009 at 8:09 am
How would one go about building a front end in ASP.NET? I looked on the asp.net website and the download is free. However, which do I download? ASP.NET Framework, ASP.NET AJAX, or Visual Web Developer? I know this is a broad question but any guidance on how to start down this path will be greatly appreciated. I really want to get away from the Access front end.
August 28, 2009 at 8:48 am
Here's my 2 cents:
Access: With Access you are relying on the Jet db engine, which in my experience is inferior to the engine supplied in SQL Server; I find the SQL you end up with is awkward (all those ugly parentheses in the WHERE clauses, the weird JOIN syntax that the Query Designer generates) and limited in its feature set. You also end up with a thicker f/e than you probably need.
ASP.NET: A good choice if you need an externally exposed application (an app used by folks outside you organization) as there would be no software to distribute. The learning curve on development can be pretty steep as you have to know a combination of a .NET language (VB or C#), HTML, Javascript, CSS, Ajax, etc.
WinForms: a shallower learning curve compared to ASP.NET as the form designer is more like what you had in Access and you can limit yourself to one development language (VB.NET or C#). In my opinion, it's easier to model complex forms in a Winforms app than it is in a Web app, but this argument holds water much better if the user base is internal.
In either environment (Winforms or ASP.NET) you would develop your DAL (data access layer -- the layer that communicates with SQL Server) in VB.NET or C#. Either (though VB.NET more so) look a bit like VBA, but there is definitely a learning curve there as well. For a Web app, the presentation layer (your forms) would be developed using a combination of .NET, HTML, etc. (all the technologies listed above) and the more complex your forms the more astute you have to be in effectively combining them.
Also in either environment there are best practices you need to be aware of that you may not have paid attention to you in Access since Access pretty much managed the DAL for you(e.g. always use parameterized Stored Procedures to avoid SQL Injection, etc -- a full list is beyond the scope of this thread).
Bpowers: you need all three. Visual Web Developer is a suite of tools that will allow you to build Web apps (e.g. ASP.NET pages) from the ground up. When you install it, it should also install the Frameworks you need. This may not be true for the Ajax libraries (I'm still using VS 2005 and I had to install that separately); Ajax is specifically designed to give you more control over the way elements on your page "post-back" (request information, or reload, from the Web server) so your app can manage network load better/smarter.
Hope this helps.
August 28, 2009 at 9:02 am
I appreciate the feedback very much. Our user base is strictly internal at this point, so I will look into Winforms. Again, I appreciate the feedback.
August 28, 2009 at 9:22 am
In the spirit of full disclosure I should point out that there are developers out there who see Winforms as a dying breed and would only recommend Web development (platform independence, no s/w to distribute, cutting edge of technology, etc.).
In my company we use a Winform app for internal use and ASP.Net for our client application, and, as I said, I prefer Winforms internally for the quicker development cycle and the ability to more easily model complex form behavior.
The safety net lies in defining your layers well (separating presentation from data access and application of business logic); if you do that right, porting a Winforms app to a Web app somewhere down the road should be a relatively easy endeavor; in that way, you're not painting yourself into a corner.
August 28, 2009 at 9:53 am
Thanks. Can you point me to some decent training material. I do not see much offered out there.
August 28, 2009 at 10:43 am
Thanks for the info.
I have a bunch of pretty complex Access db's I've developed and maintained over the past 15 years or so. I'm about halfway through changing over the backends and all the queries and code I possibly can, to SQL Server.
The reason for the changeover was db corruption and crashes on a regular basis. Just changing the be's to SQL has helped enormously. BUT I am now getting "ODBC access" errors once a week or so, where my FE's can't seem to communicate with SQL. Is changing to a different FE platform likely to help this? Or is this a network issue?
Adding to the mix: I am very close to retirement (actually retired 18 months ago but agreed to come back and help out part time) and really have no desire to learn a bunch of new software. In addition, there will be NO replacement for me, as the area I support will be gradually shut down over the next year or two. We just want stuff to keep running until then.
So... any ideas on the ODBC errors would be appreciated.
[font="Comic Sans MS"]She Through Whom All Data Flows[/font]
August 28, 2009 at 10:49 am
1. Could be network, are there any reports available on utilization at those times that its gets sketchy?
2. On the SQL Server did you set priority boost? If so I have seen a particularly busy server stop responding till it got some resources. It has been a while since I saw that though.
3. What is the utilization of the server when this is happening?
4. Do you have adequate indexes on your tables? If not the server has to work much harder to satisfy the requests, everybody suffers..
CEWII
August 28, 2009 at 11:52 am
Here is a good source for learning to develop asp.net. The data access tutorials are available in both C# and VB, whichever you prefer.
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply