May 30, 2002 at 4:58 am
quote:
>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).
I will have to disagree here overall, you should move to either a VBA based connection solution using Access or move to another language like VB, PB, etc. The reason is linked tables when opened have been know to cause many issues with blocking and unusual locking habits.
quote:
>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.
Triggers are quite usefull and can offer many bennifits you cannot get with other aspects of SQL, but like anything you need to understand and plan your code carefully to get proper output and ensure consistantancy. Your biggest help will be using SPs to control logic and flow with greater security over you application in regards to the database.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
May 30, 2002 at 5:39 am
Using .Net is an option, but there is a learning curve from VBA, aside from interop concerns.
I have to disagree on triggers. You have to use them wisely, but in many cases they are the ONLY way to enforce data integrity completely at the db level, or for instead of triggers, the only way to update an otherwise updateable view - a very handy thing to have.
Andy
May 30, 2002 at 8:16 am
Could you please explain the pros/cons of using ADO? Thanks.
quote:
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 30, 2002 at 8:52 am
Obviously a lot of fat-client fans on this thread. I was one of you once and there is no substitute if you need maximum flexibility and tight control over your UI (e.g. custom controls, multi-threading management). However, the requirement of thick client software on the desktop has a large cost associated with it in terms of system administration and SDLC is significant.
I have since been converted to fandom of web-based clients. For most business purposes a lean, clean web front-end will get your app to the masses in the shortest time-frames with minimal effort. You just have to get over the perceived performance issue of the 'block-mode-like' HTTP. I believe the world has become well accustomed to this, though. Many commercial offerings are going in this direction (e.g. OSSs).
Absolutely explore the possibilities of ASP and, my personal fave, ColdFusion for a shorter SLDC and ubiquitous client access.
May 30, 2002 at 9:17 am
Im a fan of rich clients, not necessarily fat ones. Each technology has its merits and its proponents, but in this case the original question was based on someone currently using Access and looking for an upgrade path. I think suggesting that they learn CF might not be the easiest hill to climb.
Andy
May 30, 2002 at 11:04 am
I find that vb is absolutely the best external manipulation language for sql server. i have created several small applications for manipulating dts on sql and find the api rich and useful enough that i can extend my control of sql in automation taks.
May 30, 2002 at 12:08 pm
Point taken, Andy. "The right tool for the right job" is always the order of the day.
But w/r/t climbing the CF hill, I think most with any programming background will find that barrier to entry very low (more of a speedbump than a hill). I think the learning curve is a lot less steep than Access-to-Powerbuilder or Access-to-Delphi. Further, much rich client functionality can be retained with COM and <CFOBJECT>.
Of course, ASP should provide some warm fuzzy for the MS initiated but it just doesn't have the power and time-to-market advantage of CF.
I've had the priveledge of running production support and development teams in past lives and the production support benefits of the web GUI cannot be understated.
May 30, 2002 at 12:55 pm
I'm obviously a VB/VB.Net fan and have no experience with CF, so hard for me to compare! I think .Net in general is going to alleviate some of the deployment issues and make it easier to deploy a "rich" client via internet/intranet.
From watching our web developers I feel that ASP is a definite tradeoff. Easier to deploy, not nearly as productive. My two or three cents worth!
Andy
May 31, 2002 at 6:09 pm
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. VB was orginally designed as a Windows standalone tool. It's a great tool, but it's been gradually crowbar'd into a C-S tool and it takes a lot more code and work to get what you want in a client-server app.
June 2, 2002 at 10:26 pm
I originally programmed Access (Front) / Access (Back) many years ago. then Access (Front) / SQL Server (Back) and finally VB (Front) / SQL Server (Back).
My suggestion is to upsize backend to SQL Server first. You don't have to link tables you can use MS Access as a pure client and connect to SQL using a reqular connection string.
Your performance will improve dramatically.
Next abandon your Access client and rewrite it in VB6 or VB.NET. You can preserve the majority of your code (which for MS Access is VBA - Visual Basic for Applications) which is a big advantage over Delphi, Powerbuilder.
Access front ends are slow relative to compile VB executables and difficult to distribute.
The advantage of VB6 over other technologies is user community. Go to Planet-Source-Code and every function you will ever want to write has already been posted 5 times.
Delphi community is pretty vibrant but from a carreer perspective it is not as marketable a skill. Powerbuilder should be avoided in my opinion. You will get mostly legacy work.
Regarding report writing. VB6 ships with "Data Reports" a poor man's crystal reports. they get the job done but are not fancy. Reporting is where MS Access shines. It's report object is programmable, robust and mature. Why MSFT couldn't port this engine to VB is a common question.
I like Excel as a report target - you can instantiate it as a COM object and give user's data in a format they are used to.
We are looking at moving to C# from a VB6 code base of 100s of thousands of lines of code.
But with .NET you can use whatever language you want Perl.NET, Delphi.NET, VB.NET and even Java.NET - more than 30 .NET languages are planned.
Brian Lockwood
President
LockwoodTech Software
Brian Lockwood
President
ApexSQL - SQL Developer Essentials
June 3, 2002 at 4:43 am
Actually, I'd recommend Visual Foxpro for providing a rich environment for developing your front-end. This is one of those subjective threads that can so easily degenerate into sniping about the pro's and con's of x over y.
The key thing is that you've recognised you need a proper front end, so the choice will have to be yours.
Just take care you don't get stuck with a dead end solution or something with no pedigree.
Simon
June 3, 2002 at 5:05 am
Brian, Im curious why you would port to C# from VB. When you say port do you mean rewrite?:-) Since all .net languages are supposed to be "first class", its primarily a matter of differences in the IDE for each language.
Andy
June 3, 2002 at 5:18 am
Brian
Could you tell me if you have written a class wrapper that provides a means of accessing the functionality of Excel without accessing low-level formatting calls?
The severe limitation to Excel is this archaic limit on the number of rows per sheet.
Any hints or suggestions greatly appreciated.
Simon
UK
quote:
I like Excel as a report target - you can instantiate it as a COM object and give user's data in a format they are used to.
June 3, 2002 at 5:18 am
I have to ask too, considering it is just as simple to upgrade to VB.net and when compiled it compiles into the same machine language as C#, it is just the IDE iteself that is the question. I also disagree with bcb about powerbuilder and delphi over VB in that it is how the programmer does his job. VB was designed for quick build small apps but has grown from that need. The only major problem with VB was the fact it was a single threaded environment which with .NET is not longer the case. But even before that COM components were allowed to be built multithreaded and there were trick you could use to do threading in VB 5 which were ripped away in 6. I would suggest if you are concerned your user will complain about appplication freezing you use a multithreaded developement environment but VB does have plenty of merit besides that.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
June 3, 2002 at 5:25 am
I would just point out that with VB and .NET in general you are buying into the Microsoft wish list in many ways.
The VB fans here will correct me, but how many different ways have you had to learn and forget to access back end data over the last 5 years say? Languages evolve and progress, but not so long back you needed a procedure library or 50 lines of code just to open a table, which in Foxpro was just "use clients"...
The comment has been made elsewhere that VB has a history of being all-purpose - good for community, books, support etc., but not so good for specific tasks, i.e. data handling. This harks back to the days of using COBOL for business apps and Fortran for intensive calculations.
As I said in my first post, let's agree not to disagree and get on with work.
Regards
Simon
UK
Viewing 15 posts - 16 through 30 (of 64 total)
You must be logged in to reply to this topic. Login to reply