I've got a SQL Server database. Nearly finished. It's going to go on a
single non networked machine. One day somebody might get access to it over
ADSL (probably TS), but for now it's a single user no lan.
The machine will actually be running the MSDE. Windows XP Home.
I'm quite happy, for now, to put all the business logic in SQL Server.
Triggers, SPs etc.
I've got a fair bit of Access development experience.
What's the absolute quickest way to develop a client for this?
MDB or ADP client?
OLE-DB or ODBC connection?
Bound or unbound
My experience is with Access 97/2000 FE/BE type apps.
I've got ADSL, the customer's got ADSL, so any emergency DBA type stuff I
can do via VNC.
Yours opinions, as ever, are most valued and welcome.
Mike"Mike MacSween" <mike.macsween.zerospamplease@.btinternet.com> wrote in
message news:419a6b0c$0$218$5a6aecb4@.news.aaisp.net.uk...
> What's the absolute quickest way to develop a client for this?
If this app is to be used by your clients then it should probably be a web
app. That's not going to be the RADiest but possibly the most suitable.
> Yours opinions, as ever, are most valued and welcome.
You probably didn't need to cross post this to so many groups, it really
defeats the purpose of having groups.
Michael|||"Michael C" <mculley@.NOSPAMoptushome.com.au> wrote in message
news:O%23sxkMCzEHA.3336@.TK2MSFTNGP11.phx.gbl...
> "Mike MacSween" <mike.macsween.zerospamplease@.btinternet.com> wrote in
> message news:419a6b0c$0$218$5a6aecb4@.news.aaisp.net.uk...
>> What's the absolute quickest way to develop a client for this?
> If this app is to be used by your clients then it should probably be a web
> app. That's not going to be the RADiest but possibly the most suitable.
Thanks. I don't see why it needs to be a web app. One user using the machine
that the database lives on? I want a rich client for this, not RSI inducing
mouse clicking on a web interface.
>> Yours opinions, as ever, are most valued and welcome.
> You probably didn't need to cross post this to so many groups, it really
> defeats the purpose of having groups.
Maybe. I've not got too much experience with the SQL server groups. I wasn't
sure which the best were.
Cheers, Mike|||MDB with linked tables and bound forms is surely the most
Rapid development possible: you loose only on Installation,
Flexibility, Speed, Footprint, Transactional support etc.
(david)
"Mike MacSween" <mike.macsween.zerospamplease@.btinternet.com> wrote in
message news:419a6b0c$0$218$5a6aecb4@.news.aaisp.net.uk...
> I've got a SQL Server database. Nearly finished. It's going to go on a
> single non networked machine. One day somebody might get access to it over
> ADSL (probably TS), but for now it's a single user no lan.
> The machine will actually be running the MSDE. Windows XP Home.
> I'm quite happy, for now, to put all the business logic in SQL Server.
> Triggers, SPs etc.
> I've got a fair bit of Access development experience.
> What's the absolute quickest way to develop a client for this?
> MDB or ADP client?
> OLE-DB or ODBC connection?
> Bound or unbound
> My experience is with Access 97/2000 FE/BE type apps.
> I've got ADSL, the customer's got ADSL, so any emergency DBA type stuff I
> can do via VNC.
> Yours opinions, as ever, are most valued and welcome.
> Mike
>|||"Mike MacSween" <mike.macsween.zerospamplease@.btinternet.com> wrote in
message news:419a78b5$0$221$5a6aecb4@.news.aaisp.net.uk...
> Thanks. I don't see why it needs to be a web app. One user using the
> machine that the database lives on?
Isn't that user remote? Using terminal services is a poor substitute if it
really should be a web app. If they really are the only user and there only
every will be one user then why not install the whole lot on that persons
machine.
> I want a rich client for this, not RSI inducing mouse clicking on a web
> interface.
Access is barely any richer than a web page. :-) Are you sure you didn't
word the question just to get reassurance about a decision you've already
made. Of course access is going to be the 'RADiest' front end to use but I'd
say it is far from the best. You probably need to provide more details of
what your app does and how it will be used.
Michael|||> Access is barely any richer than a web page. :-) Are you sure you didn't
How so?
> word the question just to get reassurance about a decision you've already
> made. Of course access is going to be the 'RADiest' front end to use but I'd
> say it is far from the best. You probably need to provide more details of
> what your app does and how it will be used.
Access has subdatasheets built into tables and queries, making
one/many relationships more understandable to, erm, end users without
all the technical experience in the world. Not that direct-table
editing is a good idea, but sometimes it's necessary. It's also got a
forms system that's tailored to database usage; again it's not the
world's best, but it gets the job done faster when the job is
databasing. And it's got a built-in report system. Again not the
best, but...
Where Access falls behind is as a scalable database engine, especially
a transactional one. But it's got a great front end - much better
than SQL Server. Absolutely "richer" than a web page, without some
really talented web folks.|||Thug Passion wrote:
> Access has subdatasheets built into tables and queries, making
> one/many relationships more understandable to, erm, end users without
> all the technical experience in the world. Not that direct-table
> editing is a good idea, but sometimes it's necessary. It's also got a
> forms system that's tailored to database usage; again it's not the
> world's best, but it gets the job done faster when the job is
> databasing. And it's got a built-in report system. Again not the
> best, but...
> Where Access falls behind is as a scalable database engine, especially
> a transactional one. But it's got a great front end - much better
> than SQL Server. Absolutely "richer" than a web page, without some
> really talented web folks.
I fear we're gettin off-topic, but...
- No such thing as direct table editing, unless what you meant was that
the table pages remain locked by Access while the editing is going on
- SQL Server has no front end - it's a back-end system
I agree that setting up simple forms in Access is easy, but you need
Access to use Access and it's terrible IMO for multi-user applications,
which is what SQL Server is designed for.
In addition, it's a source of problems when your ambitious end-users
start querying the database ad-hoc and generate all sorts of big, bad
SQL.
It is quick and dirty if what you're looking for is an easy way to
manage and edit data. But I would never recommend it be used for an
application or by end-users against SQL Server for anything but canned
reports.
If you're using an enterprise database, shouldn't you make sure your
application is suitable for that environment. For a single-user app and
MSDE, I guess it really doesn;t matter if it gets the job done.
David G.|||"Michael C" <mculley@.NOSPAMoptushome.com.au> wrote in message
news:eLqNzODzEHA.828@.TK2MSFTNGP10.phx.gbl...
> "Mike MacSween" <mike.macsween.zerospamplease@.btinternet.com> wrote in
> message news:419a78b5$0$221$5a6aecb4@.news.aaisp.net.uk...
>> Thanks. I don't see why it needs to be a web app. One user using the
>> machine that the database lives on?
> Isn't that user remote? Using terminal services is a poor substitute if it
> really should be a web app. If they really are the only user and there
> only every will be one user then why not install the whole lot on that
> persons machine.
OK, once again. The database and the client software to access it will be
located on a computer. One computer, located at the customers office. The
customer will look at a monitor that is connected to this computer, via a 2
metre VGA cable.
>> I want a rich client for this, not RSI inducing mouse clicking on a web
>> interface.
> Access is barely any richer than a web page. :-)
I disagree completely. I've yet to see a web page that allows keyboard
shortcuts. Or form/subform relationships. Or the ability to format reports
based upon the data values in the datasource. Or bound forms. With the form
level events that I can use to run code.
> Are you sure you didn't word the question just to get reassurance about a
> decision you've already made.
I haven't got a clue what you're talking about. My question was perfectly
clear.
> Of course access is going to be the 'RADiest' front end to use but I'd say
> it is far from the best.
So you mean MDBs or ADPs. Bound or unbound forms? OLE-DB or ODBC connection?
Infact just like I asked.
Mike|||Mike MacSween wrote:
> "Michael C" <mculley@.NOSPAMoptushome.com.au> wrote in message
> news:eLqNzODzEHA.828@.TK2MSFTNGP10.phx.gbl...
>> "Mike MacSween" <mike.macsween.zerospamplease@.btinternet.com> wrote
>> in message news:419a78b5$0$221$5a6aecb4@.news.aaisp.net.uk...
>> Thanks. I don't see why it needs to be a web app. One user using the
>> machine that the database lives on?
>> Isn't that user remote? Using terminal services is a poor substitute
>> if it really should be a web app. If they really are the only user
>> and there only every will be one user then why not install the whole
>> lot on that persons machine.
> OK, once again. The database and the client software to access it
> will be located on a computer. One computer, located at the customers
> office. The customer will look at a monitor that is connected to this
> computer, via a 2 metre VGA cable.
>> I want a rich client for this, not RSI inducing mouse clicking on a
>> web interface.
>> Access is barely any richer than a web page. :-)
> I disagree completely. I've yet to see a web page that allows keyboard
> shortcuts. Or form/subform relationships. Or the ability to format
> reports based upon the data values in the datasource. Or bound forms.
> With the form level events that I can use to run code.
>> Are you sure you didn't word the question just to get reassurance
>> about a decision you've already made.
> I haven't got a clue what you're talking about. My question was
> perfectly clear.
>> Of course access is going to be the 'RADiest' front end to use but
>> I'd say it is far from the best.
> So you mean MDBs or ADPs. Bound or unbound forms? OLE-DB or ODBC
> connection?
> Infact just like I asked.
> Mike
Use a longer cable.
--
David G.|||"David Gugick" <davidg-nospam@.imceda.com> wrote in message
news:ujmC1mGzEHA.824@.TK2MSFTNGP11.phx.gbl...
> It is quick and dirty if what you're looking for is an easy way to manage
> and edit data.
I'm looking for quick. Both in terms of user experience and developement
times.
Is Access dirty? Tell me why.
> But I would never recommend it be used for an application or by end-users
> against SQL Server for anything but canned reports.
Why not? What would you reccomend as a client application for SQL Server?
For a single user not networked application.
Or do you think I should let the user edit the SQL tables directly?
> If you're using an enterprise database, shouldn't you make sure your
> application is suitable for that environment.
I'm developing using SQL Server. I'll implement using the MSDE. I don't know
whether that counts as an 'enterprise' database. The business use is an
enterprise, money changes hands and profit is made. If that's what you mean.
But the projected number of users is 1, one, uno, un, ein.
> For a single-user app and MSDE, I guess it really doesn;t matter if it
> gets the job done.
Getting the job done is my aim!
Thanks, Mike|||"David Gugick" <davidg-nospam@.imceda.com> wrote in message
news:%23k1Q3qHzEHA.2788@.TK2MSFTNGP15.phx.gbl...
> Use a longer cable.
LOL, very good David.
Mike|||"Mike MacSween" <mike.macsween.zerospamplease@.btinternet.com> wrote in
message news:419a6b0c$0$218$5a6aecb4@.news.aaisp.net.uk...
> I've got a SQL Server database. Nearly finished. It's going to go on a
> single non networked machine. One day somebody might get access to it over
> ADSL (probably TS), but for now it's a single user no lan.
> The machine will actually be running the MSDE. Windows XP Home.
> I'm quite happy, for now, to put all the business logic in SQL Server.
> Triggers, SPs etc.
> I've got a fair bit of Access development experience.
> What's the absolute quickest way to develop a client for this?
> MDB or ADP client?
> OLE-DB or ODBC connection?
> Bound or unbound
> My experience is with Access 97/2000 FE/BE type apps.
The fastest way, without learning anything new at all, is to link to
the msde tables and ignore all the benefits of using msde. Simply
treat it as if it were a Jet. database in another .mdb file.|||Again, there is no such thing as editing a table directly. Even if you
use something like the table editor in SQL Enterprise Manager, you are
using an application to edit rows and insert/update/delete them.
And I'll reiterate: Using Access for a single user application against
any database is fine and should allow you to create your forms quickly.
You're just likely to get a lot of bias in the SQL Server groups because
many DBAs here have seen programs like Access that are used in an
enterprise cause all sorts of performance problems.
David G.|||"Thug Passion" <ThugPassion@.gmail.com> wrote in message
news:b04ce802.0411162113.61d3ed43@.posting.google.com...
> How so?
Personally I dislike using web pages, but I'd rather use a web page than an
app written in access :-)
> a transactional one. But it's got a great front end - much better
> than SQL Server.
Of course, SQL Server is a database only!!! This is like saying my Lada is
faster than a tree. :-)
> Absolutely "richer" than a web page, without some
> really talented web folks.
Barely.
Michael|||"Mike MacSween" <mike.macsween.zerospamplease@.btinternet.com> wrote in
message news:419af009$0$214$5a6aecb4@.news.aaisp.net.uk...
> OK, once again. The database and the client software to access it will be
> located on a computer. One computer, located at the customers office. The
> customer will look at a monitor that is connected to this computer, via a
> 2 metre VGA cable.
OK, I was taking into account this statement as being more solid than it
obviously was. If that's the case then I wouldn't recommend a web page.
"One day somebody might get access to it over
ADSL (probably TS), but for now it's a single user no lan."
> I disagree completely. I've yet to see a web page that allows keyboard
> shortcuts.
For the keyboard shortcuts you are right.
> Or form/subform relationships.
I don't see the problem, it just depends how you write the web page.
> Or the ability to format reports based upon the data values in the
> datasource.
For the reports I use activereports which gives me *far* more control than
access and I can show the same report in a web or windows app.
> Or bound forms.
That's a programming feature.
> With the form level events that I can use to run code.
Another programming feature but asp.net does have this.
> I haven't got a clue what you're talking about. My question was perfectly
> clear.
Maybe you did it subconciously then? It's common for programmers to word the
requirements for the project to fit their favourite tool, which I find is
especially common for access programmers.
> So you mean MDBs or ADPs. Bound or unbound forms? OLE-DB or ODBC
> connection?
Write the damn thing in dot net and be done with it. :-) It might be slower
than access but you'll get a better end product and you can develop tools
for your next project. :-)
Michael|||"Michael C" <mculley@.NOSPAMoptushome.com.au> wrote in message
news:ugwzRxOzEHA.1564@.TK2MSFTNGP09.phx.gbl...
> "Mike MacSween" <mike.macsween.zerospamplease@.btinternet.com> wrote in
> message news:419af009$0$214$5a6aecb4@.news.aaisp.net.uk...
>> OK, once again. The database and the client software to access it will be
>> located on a computer. One computer, located at the customers office. The
>> customer will look at a monitor that is connected to this computer, via a
>> 2 metre VGA cable.
> OK, I was taking into account this statement as being more solid than it
> obviously was. If that's the case then I wouldn't recommend a web page.
> "One day somebody might get access to it over
> ADSL (probably TS), but for now it's a single user no lan."
What is it about the words 'One day somebody might' and 'but for now' that
you find difficult to understand?
As for web pages being as good a client as Access front ends, just give me
the URL of one. And no, to be honest I've no interest atall in spending 100s
of hours wrestling with another new technology in order to give somebody a
web interface into a database that lives on the same machine.
>> I haven't got a clue what you're talking about. My question was perfectly
>> clear.
> Maybe you did it subconciously then?
Not sure if it was my id, ego or super-ego doing the typing.
> It's common for programmers to word the requirements for the project to
> fit their favourite tool,
yes, no doubt. I'm sure many posters to newsgroups do that. Maybe I should
do it in assembler. After all, that's another technology I've got no
experience of, so obviously better than the ones I have.
> which I find is especially common for access programmers.
It's also especially common for proper programmers to have all sorts of
preconceptions about what Access programmers do or don't do, or what their
capabilities are.
>> So you mean MDBs or ADPs. Bound or unbound forms? OLE-DB or ODBC
>> connection?
So, you clearly have great experience of Access and know it's limitations
very well. In which case, given that it's the only thing I know well, and
that there isn't time or inclination to learn anything else, and it will at
least _work_, which is the lesser of the the two Access evils? ADP or MDB?
You see to know a lot about it, so I am sure you will have good advice.
> Write the damn thing in dot net and be done with it. :-)
Why?
> It might be slower than access.
Oh good, that's a real recommendation.
> but you'll get a better end product
how better?
Micky|||"Mike MacSween" <mike.macsween.nospamplease@.btinternet.com> wrote in message
news:419bcb62$0$216$5a6aecb4@.news.aaisp.net.uk...
> What is it about the words 'One day somebody might' and 'but for now' that
> you find difficult to understand?
These are very grey terms, the fact the you specified it means that it is a
consideration of the project. I usually plan for the future.
> As for web pages being as good a client as Access front ends, just give me
> the URL of one. And no, to be honest I've no interest atall in spending
> 100s of hours wrestling with another new technology in order to give
> somebody a web interface into a database that lives on the same machine.
What is it about the words 'If that's the case then I wouldn't recommend a
web page.' that you find difficult to understand? :-)
> So, you clearly have great experience of Access and know it's limitations
> very well. In which case, given that it's the only thing I know well, and
> that there isn't time or inclination to learn anything else, and it will
> at least _work_, which is the lesser of the the two Access evils? ADP or
> MDB? You see to know a lot about it, so I am sure you will have good
> advice.
I've mainly used access as the backend and only as front end in very small
projects. I believe ADP is designed specifically for SQLServer so why not
use that?
>> It might be slower than access.
> Oh good, that's a real recommendation.
The fastest way to do something is rarely the best.
> how better?
In too many ways to list. :-)
Michael|||"Michael C" <mculley@.NOSPAMoptushome.com.au> wrote in message
news:uGi2KvPzEHA.1392@.TK2MSFTNGP14.phx.gbl...
> I've mainly used access as the backend and only as front end in very small
> projects. I believe ADP is designed specifically for SQLServer so why not
> use that?
So were they MDB front ends or ADP front ends? I know about Access as a back
end
>> how better?
> In too many ways to list. :-)
Well make a damn start!! Don't make smart alec comments about how such and
such a thing is better if you're just going to keep it to yourself. If .net
is so massively better than Access as a client to SQL Server then just tell
us the first 10. At least I could look at them and see if it's worth loading
my copy of VS.net onto the machine.
Mike|||"Mike MacSween" <mike.macsween.nospamplease@.btinternet.com> wrote in message
news:419be7a6$0$221$5a6aecb4@.news.aaisp.net.uk...
> So were they MDB front ends or ADP front ends? I know about Access as a
> back end
The projects I've done all in access have been mdb back and front ends. When
I've used SQLServer I've used either vb6 or .net as the front end. But my
limited understanding is that ADP is designed for SQLServer so is probably
the best method.
BTW, I thought because of the title of your post "RADiest Client for SQL
Server" that you were asking which front end to use, not which method to use
in access, so I may have gone off the track a little :-)
> Well make a damn start!! Don't make smart alec comments about how such and
> such a thing is better if you're just going to keep it to yourself. If
> .net is so massively better than Access as a client to SQL Server then
> just tell us the first 10. At least I could look at them and see if it's
> worth loading my copy of VS.net onto the machine.
Ok, other's have listed a few reasons already but here's the first 10 things
I thought of. Most of these apply to any programming language (eg vb6,
delphi etc).
1) Access starts off with all functionality and you have to find ways to
restrict this it, eg tricks to hide toolbars etc. It's easy to miss some
functionality or not know how to restrict it. No huge problem but I prefer
to start with nothing and add the functionality that I want myself.
2) You have much better control over forms in dot net than access, such as
border style and sizing.
3) The controls look like real windows controls, access controls have a
different look and functionality.
4) There is much greater freedom in the way you can program in .net. In
access you struggle if you don't want to do it access's way.
5) Web services.
6) Dlls, ability to componentize/encapsulate code, Usercontrols
7) oop features such as inheritance, constructors, interfaces etc.
8) Controls have a windows handle so APIs can be used. General support for
APIs and subclassing is much greater.
9) Works better with aftermarket usercontrols. Access's does support
usercontrols but it's a bit clunky.
10) Greater reusability of code, for example a class that calculates
interest paid on a loan could be used in a web page and windows app.
I'm not sure how good the report writer that comes with .net is but you'd
probably need to purchase Active Reports or Crystal Reports to have
something comparable to access reports (IMO, the report writer in access is
it's best feature :-).
Regards,
Michael|||> I fear we're gettin off-topic, but...
Not at all. Someone made the absurd claim that Access is "barely
richer" than a web page. I think the capabilites of each client have
an aweful lot to do with whether to use Access, ASP(x), or VB/C# to
build a client, don't you think?
> - No such thing as direct table editing, unless what you meant was that
What I meant was that when you edit the tables directly - "browse
editing" - through the front end provided with each system ( "Access
Datasheet View" vs "Enterprise Manager -> Right Click -> Open -> All
Rows" ), which is a bad idea but sometimes necessary, Access makes
one/many relationships easier to the type of person who would pay for
a client application.
> - SQL Server has no front end - it's a back-end system
Of course SQL Server has a front end! Calling it a "back-end system"
doesn't mean you do all your database design, tuning, management, and
all of that through code. Calling html a text format doesn't mean you
design your web site in Notepad.
> I agree that setting up simple forms in Access is easy, but you need
> Access to use Access and it's terrible IMO for multi-user applications,
> which is what SQL Server is designed for.
Which is what we're not talking about. The question was about a
single-user client app, and seemingly for somebody who has a copy of
Access. You could buy a H2 to drive to the grocery store and back,
but is there really any reason to?|||After reading all the posts, I just wondering, if it is one user on one
computer, and you currently only know Access well (as you admitted in
previous posts), why not simply use Access only (containing UI and data), it
IS the RADest client+server i one file and easiest to deploy: a simple copy
is all you need to "install". Using MSDE make things a lot more complicated,
due to MSDE's lack of user interface: you have to add some MSDE management
functionalities to your app, such as installing MSDE, database backing up
and restoring, starting and stopping MSDE service...
"Mike MacSween" <mike.macsween.nospamplease@.btinternet.com> wrote in message
news:419be7a6$0$221$5a6aecb4@.news.aaisp.net.uk...
> "Michael C" <mculley@.NOSPAMoptushome.com.au> wrote in message
> news:uGi2KvPzEHA.1392@.TK2MSFTNGP14.phx.gbl...
> > I've mainly used access as the backend and only as front end in very
small
> > projects. I believe ADP is designed specifically for SQLServer so why
not
> > use that?
> So were they MDB front ends or ADP front ends? I know about Access as a
back
> end
> >> how better?
> >
> > In too many ways to list. :-)
> Well make a damn start!! Don't make smart alec comments about how such and
> such a thing is better if you're just going to keep it to yourself. If
.net
> is so massively better than Access as a client to SQL Server then just
tell
> us the first 10. At least I could look at them and see if it's worth
loading
> my copy of VS.net onto the machine.
> Mike
>|||"Michael C" <mculley@.NOSPAMoptushome.com.au> wrote in message
news:ufejehQzEHA.1396@.tk2msftngp13.phx.gbl...
> Ok, other's have listed a few reasons already but here's the first 10
> things I thought of. Most of these apply to any programming language (eg
> vb6, delphi etc).
OK, I'm aware that programming in a proper programming language gives you a
lot more control. I've done some work in VB6.
What advantages would I gain from using .net specifically? And which
language?
Mike|||"Norman Yuan" <NoOne@.NoExist.No> wrote in message
news:SYVmd.105953$VA5.14563@.clgrps13...
> After reading all the posts, I just wondering, if it is one user on one
> computer, and you currently only know Access well (as you admitted in
> previous posts), why not simply use Access only (containing UI and data),
> it
> IS the RADest client+server i one file and easiest to deploy: a simple
> copy
> is all you need to "install". Using MSDE make things a lot more
> complicated,
> due to MSDE's lack of user interface: you have to add some MSDE management
> functionalities to your app, such as installing MSDE, database backing up
> and restoring, starting and stopping MSDE service...
You might be right. For me personally it's an educational thing. And I do
like the idea of having the robustness of a server database. Triggers and
SPs seem useful.
But I've considered going back to a simple 2 file Access setup. At least
that way the user can shove it on a USB flash drive and take it wherever she
goes.
Cheers, Mike|||(some groups dropped from the X-Post as my ISP doesn't carry them, how
many sqlserver groups are there FFS?)
David Gugick wrote:
> You're just likely to get a lot of bias in the SQL Server groups because
> many DBAs here have seen programs like Access that are used in an
> enterprise cause all sorts of performance problems.
They have to realise that Access is a tool, not a sentient being. If
they came across a bad Access application that's the fault of the person
who wrote it, not of Access itself. It's possible to write really bad
applications based on SQL Server, Oracle, DB/2, with a C++ front end,
they are the tools. The people using the tools are responsible for the
quality of the applications they write in them. The old adage: A bad
workman always blames his tools.
Of course it will be more common to see a bad Access app than say SQL
Server or Oracle as Access is more accessible to the masses of wannabe
programmers and DBAs and the way it's marketed as being easy to use and
support backed up by about a trillion ms.public.* newsgroups dedicated
to one product :rolleyes:
--
This sig left intentionally blank|||Trevor Best wrote:
> Of course it will be more common to see a bad Access app than say SQL
> Server or Oracle as Access is more accessible to the masses of wannabe
> programmers and DBAs and the way it's marketed as being easy to use
> and support backed up by about a trillion ms.public.* newsgroups
> dedicated to one product :rolleyes:
That was really my point. It's so accessible becuase it's delivered with
most Office versions, that it will inevitably end up in the wrong hands,
and hence, gets a bad rap.
--
David G.|||I think I addresses the OPs questions, but thanks for your rather
interesting snipping.
--
David G.|||"Mike MacSween" <mike.macsween.nospamplease@.btinternet.com> wrote in message
news:419c5a57$0$222$5a6aecb4@.news.aaisp.net.uk...
> OK, I'm aware that programming in a proper programming language gives you
> a lot more control. I've done some work in VB6.
> What advantages would I gain from using .net specifically? And which
> language?
1) Much better oop features than vb6 and access. This is useful even if you
don't do oop style programming.
2) New features such as web services
3) Easy to install your app once the framework is on the machine, just copy
files over.
4) IDE is much richer.
5) VB6 and access evolved over many years which created inconsistancies,
.net is new so is much more consistant.
6) API support is much stronger (even though they claim you won't need apis
with .net you do :-)
7) Looks better with windows XP style controls (on winxp)
8) Try catch is a *huge* improvement over on error goto
9) Easy to add a general error handler for the entire project without having
to put code in each function.
10) Threading support is much better (although I rarely use this myself).
11) Type casting is much stronger, reducing mistakes in code.
It takes a while to realise how good it is, it's amasing some of the
features they've added. For example, you can put 2 different breakpoint on
this line of code.
if (a < 0) a = 0;
Regards,
Michael|||Oops, I posted too soon, I would recommend c#. Out whole company changed
over from mainly vb6 programmers to c# and we were quite suprised at how
easily everyone went over.
"Mike MacSween" <mike.macsween.nospamplease@.btinternet.com> wrote in message
news:419c5a57$0$222$5a6aecb4@.news.aaisp.net.uk...
> "Michael C" <mculley@.NOSPAMoptushome.com.au> wrote in message
> news:ufejehQzEHA.1396@.tk2msftngp13.phx.gbl...
>> Ok, other's have listed a few reasons already but here's the first 10
>> things I thought of. Most of these apply to any programming language (eg
>> vb6, delphi etc).
> OK, I'm aware that programming in a proper programming language gives you
> a lot more control. I've done some work in VB6.
> What advantages would I gain from using .net specifically? And which
> language?
> Mike
>|||"Michael C" <mculley@.NOSPAMoptushome.com.au> wrote in message
news:efMfz1ezEHA.824@.TK2MSFTNGP11.phx.gbl...
> Oops, I posted too soon, I would recommend c#. Out whole company changed
> over from mainly vb6 programmers to c# and we were quite suprised at how
> easily everyone went over.
Yes, a friend of mine interviewed, or rather advertised, for a vb.net
programmer the other day and didn't get a single reply, apparently they're
all c# now. Personally I prefer Db. Though I know it's more or less the
same.
Thanks, Mike|||"Michael C" <mculley@.NOSPAMoptushome.com.au> wrote in message
news:uhyw5nezEHA.1192@.tk2msftngp13.phx.gbl...
> "Mike MacSween" <mike.macsween.nospamplease@.btinternet.com> wrote in
> message news:419c5a57$0$222$5a6aecb4@.news.aaisp.net.uk...
>> OK, I'm aware that programming in a proper programming language gives you
>> a lot more control. I've done some work in VB6.
>> What advantages would I gain from using .net specifically? And which
>> language?
> 1) Much better oop features than vb6 and access. This is useful even if
> you don't do oop style programming.
> 2) New features such as web services
> 3) Easy to install your app once the framework is on the machine, just
> copy files over.
> 4) IDE is much richer.
> 5) VB6 and access evolved over many years which created inconsistancies,
> .net is new so is much more consistant.
> 6) API support is much stronger (even though they claim you won't need
> apis with .net you do :-)
> 7) Looks better with windows XP style controls (on winxp)
> 8) Try catch is a *huge* improvement over on error goto
> 9) Easy to add a general error handler for the entire project without
> having to put code in each function.
> 10) Threading support is much better (although I rarely use this myself).
> 11) Type casting is much stronger, reducing mistakes in code.
> It takes a while to realise how good it is, it's amasing some of the
> features they've added. For example, you can put 2 different breakpoint on
> this line of code.
> if (a < 0) a = 0;
Thanks
Maybe time to look at .net and c#.
Cheers, Mike
