What to learn next: how to build for thin clients
-
Hiya all; I'm after some advice...
I'm just at the start of a big learning curve having rebuilt an Access97 application into SQL-S with an Access ADE front end. Replication & remote tcp-ip access to the SS are way better options than I was used to. I'm rapidly coming to appreciate that TSQL/stored procs & UDF's are the way to build really strong db's.
However, my fat-client VB / Access frontend is a bit disappointing in the speed & remote access respects.
My question is: what do you guys see as the best client-side tools for working with SS?
If I get to do more dev work with this company's applications, I'd like to be able to offer them internet use of the db as the baseline client. At this stage my experience is VB and TSQL; I'm happy to learn anything but all advice is welcome!
Any opinions??
Cheers
Cals
-
Personally I like working with thin clients and a web browser, but then again, that is for simple apps and requires a different mindset. Try to deliver minimal information per screen to keep the speed up and manage the workflow.
Andy prefers B thick apps, which is fine as well, better suited for some environemnts.
What types of apps are we talking about?
Steve Jones
http://www.sqlservercentral.com/columnists/sjones
The Best of SQL Server Central.com 2002 - http://www.sqlservercentral.com/bestof/
-
For internal desktop apps I believe I can build quicker/faster/better with a heavier client - but still building logical layers. Web apps have their place and I've seen some amazing ones, but you pay the price in dev time. As far as performance, stored procs are definitely the way to go - but you still have to work smart AND optimize.
Andy
-
What about using a thin client for most of the work and utilising Fat clients for any information/calc heavy work ?
Im currently building a thin client that is used for information access but launches vb clients for any modification work to the data. because its internal for the client. and the users have to be coaxed into thin client architecture 🙂 more info on the type of App would help as well i think...anyone else with ideas ?
------------------------------
Life is far too important to be taken seriously -
APPLICATIONS:
The original app is for quoting jobs; used to get a price for a contract as well as list the resources needed. this feeds into the company's finacials, as well as resource needs projections (resourcing includes staff, vehicles & equipment).
One future app would be based on providing actual orders (real values not the quote estimates).
Another possible one is a roster for the resources once ordered.
Is it an either/or question? ie, should I be worried about having to produce 2 clients?
One model I have thought about uses a fat client on the LAN link and users who need remote access are trained in a thinclient that is less feature-rich. A drawback that occurs to me is that you still have to build 2 interfaces...
Is this where you have to get smart with your sprocs & make them serve 'all comers' in terms of frontends?
-
My gut feeling for something like that would be thin client all the way! that would remove the issue of external clients who may dialup from phonelines as opposed to a LAN less transmission I would suppose. thats my 2c 🙂 Good luck...
------------------------------
Life is far too important to be taken seriously -
quote:
What about using a thin client for most of the work and utilising Fat clients for any information/calc heavy work ?...
This is the approach we have taken. We have phased out all but a few heavy clients over the last 3 years and our business runs over two main thin-client applications. We continue to use heavy clients for our ERP system, data warehousing, and maintenance/aggegation applications with very few users. I would absolutely hate to have to return to the days of the deployment nightmare that epitomizes client-server business applications. There are very few out there that have done it correctly, and we have seen no substantial benefit from fat clients when the number of users is greater than, say, 5-6. As long as you write your thin clients with the limitations of the browser and bandwidth in mind, it will be the way to go because it saves such an enormous amount of money and time in deployment and maintenance costs. Andy is right in that sometimes you may pay the price in dev time. However, the gap in development time between developing a fat and thin client is closing with the advent of .NET and more robust web development tools.
-
Deployment has always been the single biggest drawback to fat clients on an internal LAN. If you learn to manage this proactively, it can be done well and without a lot of effort, even for VB6 or similar apps (anything you can package as msi). Once you get rid of that restriction, it really changes your viewpoint about what makes sense (well, for me it does). Our bottom line machine that a user has is a P2-400 with 256m, I like to put that power to work and give the user a richer experience.
As far as two apps, that's exactly what we've done in some cases. If you do a good job of breaking out your middle tier and putting absolute minimum code in the UI, it's an easier port.
Andy
-
I like web based. I can do almost anything in ASP that I can do in a thick client.
However, I have been known to partition the application as well. On a recent development, I needed a thick client for one aspect, but I built all of the reporting in ASP delivered to a web browser. I could do this because two different sets of users were involved. "Your mileage may vary"
Joe Johnson
NETDIO,LLC.
Joe Johnson
NETDIO,LLC.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply