May 22, 2002 at 5:45 pm
Hi all,
I would like to have some advice on what's best as front-end programming language for the sql-server.
I have done some database programming in MS-Access to track invoices, engineering dwgs, etc for the office work. Lately, I have been thinking about upgrading some of my ms-access programs to a Sql server, partly due to improving security and partly due to wanting to learn something new. Assuming that MS Sql Server is going to my back_end, should I continue using MS-access as my front-end or use another programs as front-end such as fox-pro, powerbuilder ?
Any advise would be much appreciated.
Wing
May 22, 2002 at 6:27 pm
I imagine you'll get a variety of answers on this one! If you have an app already running in Access I'd recommend moving the data to SQL and linking to the tables, preserving your investment. You can then begin to leverage the additional capabilities of SQL like triggers as you need them. Aside from that, if you're comfortable in Access you'll find it a fairly easy transition to VB. Both use VBA, the biggest difference is that in VB you have to work a little harder, but in return you get more control.
Andy
May 22, 2002 at 8:58 pm
Agree with Andy - VB is the best way to go!
Also, all of the above mentioned are Microsoft products - less compatibility issues may arise.
May 23, 2002 at 5:20 am
VB is one of the simplest ways to make the change. However you can even do a lot in Access but the key is to use ADO to connect to the server instead of linking tables. But you can use any language you are most comfortable with to accomplish as long as they supprt ADO com wrapper. In fact although I am not comfortable I have written a server app in VC++. So it really is your comfort level, time constraints and overall funcationality needs of the app (Ex. VB simple to implement and quicker to do, but VC++ supports threads better and you have more control over the presentation layer without need for extending with a lot of API calls). Powerbuilder is as easy to implement for some people as VB, so it is a great choice.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
May 23, 2002 at 11:23 am
In VB, does it comes with a report writer similar to Access "report wizard"? If not, which third party report writer should I use?
May 23, 2002 at 2:06 pm
You can still use access to report off of "linked" tables. Crystal reports is a decent third party tool as well.
Terry Crosby
Terry
May 23, 2002 at 2:37 pm
I agreee, Crystal and/or Access are good options. There are other 3rd party products for reporting. Don't forget HTML/ASP either, its pretty easy to dump a query into HTML, either by building a table or by using XML/XSL. Not as refined, but the price is right.
Andy
May 24, 2002 at 1:17 am
try powerbuilder
i've done programming in both VB and PB.IMHO developing in PB is a lot faster than VB , plus compatibility with SQL is no issue and you do not need a third party reporting tool , all this if you overlook the fact that its a bit dated .. another big plus is that its object oriented 🙂 ..
May 24, 2002 at 4:55 pm
I will research into VB, PB and also Visual Foxpro which was suggested by my collegue.
Thank you all for your suggestions.
May 24, 2002 at 5:54 pm
Not sure about PB, VB isn't bad. Visual Fox will have a higher learning curve and easier to get into trouble without great benefits of VB unless you are doing OOP. VFP supports inheritence, subclassing, etc.
Steve Jones
May 24, 2002 at 6:24 pm
If inheritance and sub classing are must haves, any .Net language is worth considering too. Seems like the learning curve would be higher for VB.Net over VB6, but if you're just learning it might not be..?
Andy
May 27, 2002 at 1:07 pm
In general, specially if learning a new language is acceptable, I recommend using Delphi. Ive used it for years and have had no problems with it, and version 6 is great. Its elegant, mature, robust,with a great community of programmers behind it. With Delphi, you can use it for most of your programming needs, from console programming, database front-end programming up to graphics and game-programming. You have a wealth of database access options from the Borland Database Engine, to ADO, to "native" drivers. With Kylix, you can easily port your Delphi program to Linux.
However, if using non-Microsoft tools does not appeal to you, but you do have time to learn a new language, I recommend using C#. It already approximates the elegance and power of Delphi but the runtime requirements are a pain (at least until most of your clients have the .NET runtime pre-installed). Although Delphi is more mature than C# and .NET in general, the prime designer of C# and .NET is none other than the original designer of Delphi and Turbo Pascal (Anders Hejlsberg), who Microsoft pirated from Borland a few years back. Thus, C# has a lot of similarities with Delphi and it wont be surprising, maybe even to be expected, that C# will attain and maybe even surpass Delphi's strengths.
If you want to stay using Microsoft tools, and dont much time to learn a new language/ programming paradigm, or are just wanting to develop some small/quick & dirty application, use VB...not VB.net, not VBA.
May 27, 2002 at 4:21 pm
A lite copy of Crystal Reports comes with VB.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
May 30, 2002 at 3:14 am
>If you have an app already running in Access I'd recommend moving the data to SQL and linking to the tables, preserving your investment.
Agree, although I would start doing any need forms in winforms in .NET and call the exe from a button in Access. That way you get to use your investment in Access and gradually move to .NET, (which enables you to do a much better solution).
>You can then begin to leverage the additional capabilities of SQL like triggers as you need them.
Triggers are probably the only feature of SQL I would avoid.
Adam
May 30, 2002 at 3:14 am
>If you have an app already running in Access I'd recommend moving the data to SQL and linking to the tables, preserving your investment.
Agree, although I would start doing any need forms in winforms in .NET and call the exe from a button in Access. That way you get to use your investment in Access and gradually move to .NET, (which enables you to do a much better solution).
>You can then begin to leverage the additional capabilities of SQL like triggers as you need them.
Triggers are probably the only feature of SQL I would avoid.
Adam
Viewing 15 posts - 1 through 15 (of 64 total)
You must be logged in to reply to this topic. Login to reply