Front-end for Sql server - What's best?

  • VB.NET vs C# cartoons

    http://www.angrycoder.com/article.aspx?cid=12&y=2002&m=2&d=25

    http://www.angrycoder.com/article.aspx?cid=12&y=2002&m=2&d=18

    Brian Lockwood

    President

    LockwoodTech Software

    Brian Lockwood
    President
    ApexSQL - SQL Developer Essentials

    http://www.apexsql.com/blog

    Stand up for an Independent SQL Community - be Informed

  • Hi all

    Bugger it, im adding my 2cents worth here 🙂

    I am relatively new to the Microsoft realm as the DBA, but saying that and the projects itve been involved with the following has proved to be a good choice that performs well:

    ASP

    COM+ (VB code) and proxied as beed be

    SS2k (stored procs and selected views and denormalisation as req)

    unfortunatly though, XML has been used for ALL vb-code class methods (in/outs), this has created major CPU problems and is now difficult to resolve. In the end, DONT use XML unless its being exposed as a webservice etc, its simply not work the CPU hit you will take and the excuse "but we can use any method as a service now" is NOT an architectural smart.

    I have done some side work with ASPNet, fast apps and great dev environment (i believe MS have got it right!).

    As always, no matter the front-end, SQL performance needs to be thoroughly analysed and bought to peoples attendion asap before the app becomes too mature.

    Cheers

    Chris


    Chris Kempster
    www.chriskempster.com
    Author of "SQL Server Backup, Recovery & Troubleshooting"
    Author of "SQL Server 2k for the Oracle DBA"

  • quote:


    The proper tool for any job is that tool which was originally designed specifically for that job. For 2-tier client-server (which it sounds like you want), VB is NOT the best way to go! (Sorry to anger a few.:) If you're building an old style two-tier client-server app then PB (or Delphi) beats the pants off VB, because it was designed purely as a 2-tier C/S app tool. . . .


    We are using Access Data Projects in Access XP (2002). The ADP format seems like a good two tier approach once one converts Access mdb queries to the right mix of stored procedures and functions. Since I do not know PB, I can not compare ADP and PB.

    Edited by - Bill Hallinan on 06/06/2002 08:51:44 AM

  • ADPs????

    Access Data Pages are a big fat ActiveX control in a web page - that type of approach died 3 years ago.

    Also scripting without a debugging environment mean that ADPs wont live for long.

    Adam

    http://www.ssw.com.au

  • In the original post, wkwong mentioned "wanting to learn something new" which I think is an important point.

    All the technologies mentioned are capable of doing what he wanted but some of them are clearly a dead end when it comes to learning.

    If you really are looking both to produce a solution and learn something new then surely using .NET technologies must be the most advisable. If you prefer a non-MS path then Delphi (or even Java) may be your next best options. But surely *starting* to learn VB6 or ASP 3 *now* is a waste of time.

    Any thoughts?

  • I dont think learning VB6 or ASP3 would be a waste of time, there is a LOT of code out there written in both. Thats good since you may end up needing to maintain a solution written in either, or you may be looking for sample code/articles/books, of which there is plenty. Most of the skills learned will transfer (if you can see the high level patterns), syntax will change some of course.

    Andy

    http://www.sqlservercentral.com/columnists/awarren/

  • Also many companies have invested too much money in purchasing their developers these tools. Many will also decide that VB.NET as well as the whole .NET framework need to age at least one revision to make sure unforseen security holes are plugged before they decide to use. And my opinion is to be a good developer you should understand a language from it's basic start. I am teaching myself Visual C++ and have read mostly books on C and C++, now I have gotten to the point I can do most of what want except I am programming the GUI interface which is mostly done except for a few items I cannot find any existing examples or similar code for. In fact for someone wanting to jump in I would point to VB not .NET as a person moving to .NET I would suggest getting in some C knowledge do to the new classing in .NET. You don't have to have the latest and greatest programming platform to do your best it is better to understand what you are doing than have the tool add a bunch of junk just because yo can drag and drop code.

    "Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)

  • A lot of what you use depends on what you're doing. "Right tool for the right job" type of thing. I've found that if you want to grow an Access App into something more robust, Visual Fox is an option worth a lot of consideration. It has a powerfull local data manipulation engine. It has is own reporting engine that is very capable. You can hook into Crystal Reports if you want. It can connnect to SQL through any number of protocols (ADO, OLEDB, ODBC, XML). It's .Net compatible and it has a decent learning curve. (Easier than C++ and C#. Comparable to ASP and more difficult than any of the VB family of tools.) BTW I include Access in that last group. It's also an OOP language like C++ which gives you a lot of options on how to build the application. Not to mention all of the advantages that flow from an OOP language.

    My two bits worth

    HTH : )

  • All these VB and Access Guys that are informing you that VB and Access are the best front end are full of it.

    If you want a truly powerful RAD front-end tool for SQL Server is by far, hands-down Visual FoxPro. With the mix of having remote views and SQL Pass-Through capability development becomes a snap! Crackle! Pop!

    I've personally have experience working with a VB shop where VB fell completely apart while working with SQL Server as the back-end.

    Besides VB is dead and is being replaced by VB.NET - another language that is being rediculed right to its face.


    Victor Campos, MCP/MCSD
    Options Software Consultant

  • Language is a choice and all have there merrits. Please refrain from being rude. I work with VB, ASP, JAVA, VC++, and ACCESS and I never have any troubles with my apps. If a program fails then it is usually due to poor programming with respect to the unexpected. VFP can be just as bad as VB or any other if errors are not properly handled.

    "Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)

  • Totally agree with Antares - we appreciate all comments, but let's have a professional discussion. I'd be curious to hear more about "VB" falling apart, in my experience it's usually due to being applied very badly, but if there is a true flaw - I'm here to learn!

    Andy

    http://www.sqlservercentral.com/columnists/awarren/

  • We use nothing but Delphi to write front ends (we just moved from D5 to D6) for all of our in-house applications (purchasing, contacts, project management, etc). I was a non-programmer, spent about a year on Access 2000 goodies, and then moved to Delphi. It's been fairly straightforward and after two and a half years of using it I'm able to do just about anything I want. We work off a SQL Server 2K setup in a Win2K/Office2K shop. The Delphi apps are solid and the third party tools (particularly DevExpress) make my life incredibly easy.

  • I would recommend something a little different. You ask about which *language* you should use to build your front end. If you really want to use Access, then VB may be the way to go. But if you just want a front end, and you are going to learn a language, I would recommend skipping Microsoft-specific solutions because you (or your client) may want to migrate to another database at some point in the future.

    To develop a more portable solution, you could use a scripting language like Python or a more robust web application development platform like Zope (or both). This will give you a cross-platform solution that can scale and migrate. If you decide to use Python, I strongly recommend the book Python Web Programming. The author goes into detail about how to create a database front end that is portable and migrateable.

    Don't get me wrong, I use SQL Server and love it (especially the full text indexing and proximity searching). But I don't feel like locking myself into using it indefinitely by building a solution that is entirely dependent on it.

  • quote:


    ADPs????

    Access Data Pages are a big fat ActiveX control in a web page - that type of approach died 3 years ago.

    Also scripting without a debugging environment mean that ADPs wont live for long.

    Adam

    http://www.ssw.com.au


    You missed the point here and obviously don't know much about Access 2000/XP. The newer versions of Access support two versions of storage: the traditional Jet .MDB [ODBC] and new .ADP (Access Data Project) [ADO] which is directly linked to SQL Server.

    If somebody wants to work with easy & flexible Access with SQL backend, don't use Access 2000 ADP, go for Access XP.

    I'm not sure if Access' tools for SQL objects are any good, because I handle everything about SQL Server 2000 using its own tools (Enterprise Manager, Query Analyzer). That's teh best way to keep control of your database.

    Best regards, Jani

  • Let's go back to the question. The answer for what is best is whatever you are familiar with or willing to learn that will make give you the required results in the time set forth. SO if this is an ASAP project and you are familiar with VB, use VB. If Delphi, use Delphi. The is truely no one product that is absolutely better than the others it is all in how the progrmmer does the work. Use what you know and build from it. If you have time to learn something to build it in then pick what interest you most but keep in mind who will have to deal with it later. Also weigh needs like distribution and support files and how much documentation you make on it will help all solve the problems that will occurr when first built. Make sure you properly handle errors (a bad habit that VB programmers have is to place an "ON ERROR RESUME NEXT" in their code and forget to turn off when the point of th expected error occurrs). A lot of great suggestions have been made here and lot of arguements for their case brought up. The point is when all is said and done it has to be supported, make sure you can. But nothing is better than anything else when you boil it down.

    "Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)

Viewing 15 posts - 46 through 60 (of 64 total)

You must be logged in to reply to this topic. Login to reply