|
P: n/a
|
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
| |
Share this Question
|
P: n/a
|
"Mike MacSween" <mi**************************@btinternet.com> wrote in
message news:41*********************@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 | |
|
P: n/a
|
"Michael C" <mc*****@NOSPAMoptushome.com.au> wrote in message
news:O%****************@TK2MSFTNGP11.phx.gbl... "Mike MacSween" <mi**************************@btinternet.com> wrote in
message news:41*********************@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 | |
|
P: n/a
|
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" <mi**************************@btinternet.com> wrote in
message news:41*********************@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
| |
|
P: n/a
|
On Tue, 16 Nov 2004 21:03:05 -0000, "Mike MacSween"
<mi**************************@btinternet.com> wrote:
Hi Mike,
You got to have your priorities straight. In this case you're saying
that rapid development is your main concern, and that it should
override any other concern.
I'm assuming another important concern is implicit: YOU develop the
front-end, so it needs to be done with YOUR skills. RAD and developing
a new skill don't go together.
I think it's not nice to say to Michael C that you don't want to
develop RSI in a web app. If (which even the poster doubts) a webapp
is the RADest tool, then you'll have to live with some RSI (assuming
that claim is correct).
Given your skills the choice seems obvious to me: use an MDB with
attached tables to the SQL Server over ODBC, and use bound forms (heck
- wizard generated is best for RAD) wherever possible. You already
have all skills needed to pull this off, and there are few if any RAD
tools more efficient than this.
You give up some performance, scalability, security, coolness, etc.
but if you have your priorities straight, that was a conscious
decision.
-Tom. 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 | |
|
P: n/a
|
"Mike MacSween" <mi**************************@btinternet.com> wrote in
message news:41*********************@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 | |
|
P: n/a
|
> 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. | |
|
P: n/a
|
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. | |
|
P: n/a
|
"Michael C" <mc*****@NOSPAMoptushome.com.au> wrote in message
news:eL*************@TK2MSFTNGP10.phx.gbl... "Mike MacSween" <mi**************************@btinternet.com> wrote in
message news:41*********************@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 | |
|
P: n/a
|
"Tom van Stiphout" <no*************@cox.net> wrote in message
news:qh********************************@4ax.com... On Tue, 16 Nov 2004 21:03:05 -0000, "Mike MacSween"
<mi**************************@btinternet.com> wrote:
Hi Mike,
You got to have your priorities straight. In this case you're saying
that rapid development is your main concern, and that it should
override any other concern.
Yup
I'm assuming another important concern is implicit: YOU develop the
front-end, so it needs to be done with YOUR skills. RAD and developing
a new skill don't go together.
Sure
I think it's not nice to say to Michael C that you don't want to
develop RSI in a web app.
Why not nice? My experience is that overuse of the mouse is what hurts. And
that's what you have to do in a web browser. Web apps are slow and clumsy
for datacentric applications. Access provides the possibility of a
keyboard-centric form design, which is better. There's no need for this to
be a web app.
If (which even the poster doubts) a webapp
is the RADest tool, then you'll have to live with some RSI (assuming
that claim is correct).
No I won't, and neither will the user. She's a professional violinist, I'm
not doing that to her.
Given your skills the choice seems obvious to me: use an MDB with
attached tables to the SQL Server over ODBC, and use bound forms (heck
- wizard generated is best for RAD) wherever possible. You already
have all skills needed to pull this off, and there are few if any RAD
tools more efficient than this.
Right. So you think that's quicker than ADPs via OLE-DB? That was my
question.
You give up some performance,
Compared to what other client?
scalability,
That's not really an issue, but what would give me greater scalability?
Unbound forms, or a VB client or something else?
security,
Why? Perhaps you could explain. Not that it's really an issue again.
coolness,
Not sure what you mean there.
etc.
such as?
but if you have your priorities straight, that was a conscious
decision.
My priorities are very straight. I want the back end to be MSDE, and the
front end to be the fastest way to develope an app that will allow a single
local user to interact, read/write/edit/delete, with the database.
Scalability and security are not issues speed of development a low
maintenance are.
Cheers, Mike | |
|
P: n/a
|
Tom
Seeing as you mention 'developing a new skill' the precise reason I don't
really want to develop a client in VB/C#/Delphi/C++/ASP/Java and a middle
DAL tier of COM (?) objects (see, I don't really know what I'm talking
about), is because I'm learning about SQL Server, which is enough at the
moment.
That's one new (for me) technology to grapple with for now.
That's why I was asking about the fastest client to develop in, and asking
about the choices between the various Access access methods! Of course if
there's another way of developing a client to a local SQL Server that is
comparable, in development times to Access then I'm all ears.
Cheers, Mike
"Tom van Stiphout" <no*************@cox.net> wrote in message
news:qh********************************@4ax.com... On Tue, 16 Nov 2004 21:03:05 -0000, "Mike MacSween"
<mi**************************@btinternet.com> wrote:
Hi Mike,
You got to have your priorities straight. In this case you're saying
that rapid development is your main concern, and that it should
override any other concern.
I'm assuming another important concern is implicit: YOU develop the
front-end, so it needs to be done with YOUR skills. RAD and developing
a new skill don't go together.
I think it's not nice to say to Michael C that you don't want to
develop RSI in a web app. If (which even the poster doubts) a webapp
is the RADest tool, then you'll have to live with some RSI (assuming
that claim is correct).
Given your skills the choice seems obvious to me: use an MDB with
attached tables to the SQL Server over ODBC, and use bound forms (heck
- wizard generated is best for RAD) wherever possible. You already
have all skills needed to pull this off, and there are few if any RAD
tools more efficient than this.
You give up some performance, scalability, security, coolness, etc.
but if you have your priorities straight, that was a conscious
decision.
-Tom.
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 | |
|
P: n/a
|
Mike MacSween wrote: "Michael C" <mc*****@NOSPAMoptushome.com.au> wrote in message
news:eL*************@TK2MSFTNGP10.phx.gbl... "Mike MacSween" <mi**************************@btinternet.com> wrote
in message news:41*********************@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. | |
|
P: n/a
|
"David Gugick" <da***********@imceda.com> wrote in message
news:uj*************@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 | |
|
P: n/a
|
"David Gugick" <da***********@imceda.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl... Use a longer cable.
LOL, very good David.
Mike | |
|
P: n/a
|
"Mike MacSween" <mi**************************@btinternet.com> wrote in
message news:41*********************@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. | |
|
P: n/a
|
On Wed, 17 Nov 2004 06:44:08 -0000, "Mike MacSween"
<mi**************************@btinternet.com> wrote:
Comments in-line. "Tom van Stiphout" <no*************@cox.net> wrote in message
news:qh********************************@4ax.com.. . On Tue, 16 Nov 2004 21:03:05 -0000, "Mike MacSween"
<mi**************************@btinternet.com> wrote:
Hi Mike,
You got to have your priorities straight. In this case you're saying
that rapid development is your main concern, and that it should
override any other concern.
Yup
I'm assuming another important concern is implicit: YOU develop the
front-end, so it needs to be done with YOUR skills. RAD and developing
a new skill don't go together.
Sure
I think it's not nice to say to Michael C that you don't want to
develop RSI in a web app.
Why not nice? My experience is that overuse of the mouse is what hurts. And
that's what you have to do in a web browser. Web apps are slow and clumsy
for datacentric applications. Access provides the possibility of a
keyboard-centric form design, which is better. There's no need for this to
be a web app.
It's an example of another unspoken priority you had.
If (which even the poster doubts) a webapp
is the RADest tool, then you'll have to live with some RSI (assuming
that claim is correct).
No I won't, and neither will the user. She's a professional violinist, I'm
not doing that to her.
It's an example of another unspoken priority you had.
Given your skills the choice seems obvious to me: use an MDB with
attached tables to the SQL Server over ODBC, and use bound forms (heck
- wizard generated is best for RAD) wherever possible. You already
have all skills needed to pull this off, and there are few if any RAD
tools more efficient than this.
Right. So you think that's quicker than ADPs via OLE-DB? That was my
question.
For you it is, since you don't know ADP + OLE-DB as well. For people
who know both, it's mostly a wash. It *is* nice that queries in an MDB
can call local functions. I understand that's promised for SQL Server
2005 as well.
You give up some performance,
Compared to what other client?
Compared to ADP. The ODBC interface is not actively being developed
anymore, so you don't get the latest (speed) improvements.
scalability,
That's not really an issue, but what would give me greater scalability?
Unbound forms, or a VB client or something else?
True client/server computing is more scalable than MDB+ODBC.
security,
Why? Perhaps you could explain. Not that it's really an issue again.
You need to give the user access to the raw tables. That's mostly a
no-no in client/server and more secure environments, where the data
can only be modified in ways that the designers envisioned through a
layer of stored procedures with access rights.
coolness,
Not sure what you mean there.
Personal taste mostly. But any way you turn it RAD means get there
quick, and so the best design or the best looking design is not as
high of a priority.
etc.
such as?
but if you have your priorities straight, that was a conscious
decision.
My priorities are very straight. I want the back end to be MSDE, and the
front end to be the fastest way to develope an app that will allow a single
local user to interact, read/write/edit/delete, with the database.
Scalability and security are not issues speed of development a low
maintenance are.
Cheers, Mike
Cheers.
-Tom. | |
|
P: n/a
|
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.
| |
|
P: n/a
|
Mike
we use sql server 7 to run our ERP system and use ms-access to provide
user reports
we also use ms-access, with a seperate set of sql-server tables, for
our commission system
in the case of reporting on the ERP data, we created sql-server views
of the tables to use in ms-access (non updateable), and we created
links to them in access
and in the case of the commission tables, we link directly to the
tables and use sql server permissions to define who can update
in both cases, we use an odbc link using the sqlServer driver
the only issue with linked ODBC tables is that you can have only one
index in ms-access (usually the primary key)
so if you're using queries where there's a need to use extra indices
(for performance), create the indices in sql server and either
a) create passthrough queries in access
b) or create views in sql server and link them into access
(they look like tables)
c) or, for parameterized queries, create stored procedures in sql
server
and create passthrough queries in access to pass the parameters
hope this helps
"Mike MacSween" <mi**************************@btinternet.com> wrote in message news:<41*********************@news.aaisp.net.uk>.. . Tom
Seeing as you mention 'developing a new skill' the precise reason I don't
really want to develop a client in VB/C#/Delphi/C++/ASP/Java and a middle
DAL tier of COM (?) objects (see, I don't really know what I'm talking
about), is because I'm learning about SQL Server, which is enough at the
moment.
That's one new (for me) technology to grapple with for now.
That's why I was asking about the fastest client to develop in, and asking
about the choices between the various Access access methods! Of course if
there's another way of developing a client to a local SQL Server that is
comparable, in development times to Access then I'm all ears.
Cheers, Mike
"Tom van Stiphout" <no*************@cox.net> wrote in message
news:qh********************************@4ax.com... On Tue, 16 Nov 2004 21:03:05 -0000, "Mike MacSween"
<mi**************************@btinternet.com> wrote:
Hi Mike,
You got to have your priorities straight. In this case you're saying
that rapid development is your main concern, and that it should
override any other concern.
I'm assuming another important concern is implicit: YOU develop the
front-end, so it needs to be done with YOUR skills. RAD and developing
a new skill don't go together.
I think it's not nice to say to Michael C that you don't want to
develop RSI in a web app. If (which even the poster doubts) a webapp
is the RADest tool, then you'll have to live with some RSI (assuming
that claim is correct).
Given your skills the choice seems obvious to me: use an MDB with
attached tables to the SQL Server over ODBC, and use bound forms (heck
- wizard generated is best for RAD) wherever possible. You already
have all skills needed to pull this off, and there are few if any RAD
tools more efficient than this.
You give up some performance, scalability, security, coolness, etc.
but if you have your priorities straight, that was a conscious
decision.
-Tom.
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 | |
|
P: n/a
|
"Thug Passion" <Th*********@gmail.com> wrote in message
news:b0**************************@posting.google.c om... 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 | |
|
P: n/a
|
"Mike MacSween" <mi**************************@btinternet.com> wrote in
message news:41*********************@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 | |
|
P: n/a
|
"Michael C" <mc*****@NOSPAMoptushome.com.au> wrote in message
news:ug**************@TK2MSFTNGP09.phx.gbl... "Mike MacSween" <mi**************************@btinternet.com> wrote in
message news:41*********************@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 | |
|
P: n/a
|
> > Given your skills the choice seems obvious to me: use an MDB with attached tables to the SQL Server over ODBC, and use bound forms (heck
- wizard generated is best for RAD) wherever possible. You already
have all skills needed to pull this off, and there are few if any RAD
tools more efficient than this.
Right. So you think that's quicker than ADPs via OLE-DB? That was my
question.
If you've never worked with the (frequently undocumented) quirks of
ADP's, then linked tables in an MDB will be faster. But I guess it
really depends on how much you've done on the back end. You mentioned
stored procedures a while back -- you probably shouldn't have written
backend programming without knowing what you want to do on the front
end. If you have heavily invested time on the stored procedures, then
the learning curve for ADP's might be worth it. | |
|
P: n/a
|
"Nicole" <ni*****@namg.com> wrote in message
news:7f**************************@posting.google.c om...
Thanks Nicole Right. So you think that's quicker than ADPs via OLE-DB? That was my
question.
If you've never worked with the (frequently undocumented) quirks of
ADP's, then linked tables in an MDB will be faster. But I guess it
really depends on how much you've done on the back end. You mentioned
stored procedures a while back -- you probably shouldn't have written
backend programming without knowing what you want to do on the front
end. If you have heavily invested time on the stored procedures, then
the learning curve for ADP's might be worth it.
The back end is mainly the the table structure and relationships, a small
number of triggers, to enforce alternate keys and mandatory 'one' side
relationship. And a couple of stored procs for some data copy type things.
But that could be done anyhow, I guess.
Could you explain the 'more stored procedures means ADPs are better' thing
that you seem to be saying? Is the converse true - MDBs = no SPs?
Cheers, Mike | |
|
P: n/a
|
"Mike MacSween" <mi************************@btinternet.com> wrote in message
news:41*********************@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 | |
|
P: n/a
|
"Michael C" <mc*****@NOSPAMoptushome.com.au> wrote in message
news:uG**************@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 | |
|
P: n/a
|
"Mike MacSween" <mi**************************@btinternet.com> wrote in
news:41*********************@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
In my opinion an ADP with bound forms is the raddiest. I would not use an
ADP for these reasons:
1) if the adp can access the db, any one who uses the adp can, with a
little ingenuity access the db from another access (or other) application
with exactly the same permissions; this may compromise security; 2) an
adp's connections are multiple (not just double as is sometimes stated)
bizarre and arcane; 3) adps are inconsistent in that sometimes code or
forms or reports will work one way with one table, view or whatever, but
not work that way with another table, view or whatever which seems to be
of exacty the same type; 4) adps updating of records is sometimes a
struggle to make work; 5) adps have lots of bizarro idiosyncracies.
Having developed a fairly major ADP and several medium ones I can say
that, "You can't really predict what the hell is going to happen with an
ADP!" If this were ever true of MDBs, it way more true of ADPs.
MDBs with ODBC connections might be as raddy. Since I haven't used these I
can't say which of the problems noted above occur in these too. But I
wouldn't go this route because I don't want to use ancient technology.
Well HTAs are pretty good too, but they require Internet Explorer. I don't
use IE any more. I think Firefox is a superior browser and it has not
f___ked my computer yet, something IE has accomplished many times.
So, I'd download one of the beta Visual Studio 2005 versions from http://lab.msdn.microsoft.com/vs2005/ (free) and slog through that. But I
wouldn't be too awfully rad.
Except, truth is I'm disapointed with Access and MS in general and am not
sure where to turn.
--
Lyle
--
use iso date format: yyyy-mm-dd http://www.w3.org/QA/Tips/iso-date
--
The e-mail address isn't, but you could use it to find one. | |
|
P: n/a
|
"Mike MacSween" <mi************************@btinternet.com> wrote in message
news:41*********************@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 | |
|
P: n/a
|
Mike,
First, booo! for all the cross-posting to other newsgroups. Next, I'd
probably attach the ADODB object library to my Visual Basic Project and use
Visual Studio. If this is your first db-client project then there is a lot
of code that has to get done involving configuration, exception handling,
db-connectivity, etc. Access . . . is a pain as a development tool because
you need the application to run things you create with it. It also fiddles
with the way things work in Visual Basic to make it easier for the admin
assistant to create a database instead of an expensive programmer. Visual
Studio is a pretty good IDE and a good RAD tool. Microsoft includes quite a
bit of sample code and other useful libraries in the retail version on the
shelves of your local computer store. The reasons I like Access for the
stuff I do at home are the very reasons I'd not use it for stuff I wanted to
sell--ease of use, ease of change, loose adherance to standards so non-geeks
can do useful things with it. VB and SQL Server is a pretty good
combination.
Now, in my brief but brilliant career as a contract programmer I saw more
than my share of "oh, just do something simple & cheap in Access" projects
turn into scope creeping, budget eating beasts. I've heard more than one
client promise, promise, promise that it's really not going to be that big
or popular only to start coding and find out that my original one user is in
fact five and oh, by the way, a couple guys in HR think this is cool, could
you include them too, and the VP of Technology is interested . . . I
usually under promise and then design assuming the application will grow in
scope and I'll need to accomodate the changes. So, your client says one
box, no lan. Right. Code for 5 to start with and plan on finding out later
that it will be on a lan hosted by a server.
"Mike MacSween" <mi**************************@btinternet.com> wrote in
message news:41*********************@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. | |
|
P: n/a
|
"Alan Webb" <kn*****@hotmail.com> wrote in
news:Xo********************@comcast.com: Now, in my brief but brilliant career as a contract programmer I
saw more than my share of "oh, just do something simple & cheap in
Access" projects turn into scope creeping, budget eating beasts.
I've heard more than one client promise, promise, promise that
it's really not going to be that big or popular only to start
coding and find out that my original one user is in fact five and
oh, by the way, a couple guys in HR think this is cool, could you
include them too, and the VP of Technology is interested . . . I
usually under promise and then design assuming the application
will grow in scope and I'll need to accomodate the changes. So,
your client says one box, no lan. Right. Code for 5 to start
with and plan on finding out later that it will be on a lan hosted
by a server.
Five users is by no means going to tax the capabilities of Access.
With an MSDE or even full SQL Server back end, the issues become
more one of choices of data access methods and doing your
appropriate client/server data retrieval.
If you have trouble writing MDB applications for five users (or even
10), then you really oughtn't be giving advice on Access application
design.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc | |
|
P: n/a
|
> 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? | |
|
P: n/a
|
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" <mi************************@btinternet.com> wrote in message
news:41*********************@news.aaisp.net.uk... "Michael C" <mc*****@NOSPAMoptushome.com.au> wrote in message
news:uG**************@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
| |
|
P: n/a
|
"Michael C" <mc*****@NOSPAMoptushome.com.au> wrote in message
news:uf**************@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 | |
|
P: n/a
|
"Norman Yuan" <No***@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 | |
|
P: n/a
|
(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 | |
|
P: n/a
|
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. | |
|
P: n/a
|
I think I addresses the OPs questions, but thanks for your rather
interesting snipping.
--
David G.
| |
|
P: n/a
|
> The back end is mainly the the table structure and relationships, a small number of triggers, to enforce alternate keys and mandatory 'one' side
relationship. And a couple of stored procs for some data copy type things.
But that could be done anyhow, I guess.
Could you explain the 'more stored procedures means ADPs are better' thing
that you seem to be saying? Is the converse true - MDBs = no SPs?
ADP's integrate very well and very easily with stored procedures,
whereas MDB's do not. I haven't personally tried to run an SP from an
MDB, but I see no reason why you couldn't declare an explicit
connection and call it in VBA. Whereas in an ADP, you can use stored
procedures as Recordsources for forms, reports, etc.
I like ADP's, because I think their benefits outweigh their
occassional frustrations, but in your situation, an MDB would probably
be faster and easier for you. | |
|
P: n/a
|
"Nicole" <ni*****@namg.com> wrote in message
news:7f**************************@posting.google.c om...
Thanks Nicole Could you explain the 'more stored procedures means ADPs are better'
thing
that you seem to be saying? Is the converse true - MDBs = no SPs?
ADP's integrate very well and very easily with stored procedures,
whereas MDB's do not. I haven't personally tried to run an SP from an
MDB, but I see no reason why you couldn't declare an explicit
connection and call it in VBA. Whereas in an ADP, you can use stored
procedures as Recordsources for forms, reports, etc.
I like ADP's, because I think their benefits outweigh their
occassional frustrations, but in your situation, an MDB would probably
be faster and easier for you.
I don't mind learning. The question is do ADPs have a future and are
therefore worth learning?
Cheers, Mike | |
|
P: n/a
|
Lyle Fairfield wrote: MDBs with ODBC connections might be as raddy. Since I haven't used these I
can't say which of the problems noted above occur in these too. But I
wouldn't go this route because I don't want to use ancient technology.
I'd call it "proven" technology rather than ancient. It is raddy and
there's few problems with it provided you know what you're doing.
Well HTAs are pretty good too, but they require Internet Explorer. I don't
use IE any more. I think Firefox is a superior browser and it has not
f___ked my computer yet, something IE has accomplished many times.
I Completely agree. Shame some people still insist on writing web pages
that require IE, Firefox is W3C no more and no less, every page that
can't display on Firefox is a hacked up POS, if you're going to write a
web page, write it for Firefox, if another browser doesn't work properly
then it's the fault of the browser.
--
This sig left intentionally blank | |
|
P: n/a
|
"Lyle Fairfield" <Lo******@FFDBA.Com> wrote in message
news:Xn*******************@130.133.1.4...
Thanks Lyle. I value your input on ADPs, seeing as I know you at least have
used them 'in anger', as it were.
What's an HTA?
Cheers, Mike
| |
|
P: n/a
|
"Mike MacSween" <mi************************@btinternet.com> wrote in
news:41*********************@news.aaisp.net.uk: "Lyle Fairfield" <Lo******@FFDBA.Com> wrote in message
news:Xn*******************@130.133.1.4...
Thanks Lyle. I value your input on ADPs, seeing as I know you at least
have used them 'in anger', as it were.
A year ago I was a great fan of ADPs. That was then.
What's an HTA?
HTML Application http://msdn.microsoft.com/workshop/a...taoverview.asp
There beautiful and easy! They require Internet Explorer!
Argggggghhhhhhhhh! | |
|
P: n/a
|
Trevor Best <no****@besty.org.uk> wrote in
news:41**********************@news.zen.co.uk: Lyle Fairfield wrote: MDBs with ODBC connections might be as raddy. Since I haven't used
these I can't say which of the problems noted above occur in these
too. But I wouldn't go this route because I don't want to use ancient
technology.
I'd call it "proven" technology rather than ancient.
Like pushrod engines? | |
|
P: n/a
|
Unfortunately, Firefox is buggy, slow, and doesn't handle multiple open web
pages well. The whole point of tabbed browsing is lost if you cant have
more than 5 complex web pages open at once. It's also a beautiful idea to
say that 'pages should be written for Firefox', but that to me is just as
short-sighted as saying 'pages should be written for IE'. You certainly
don't write your Access programs just to be used by only the most careful
users; why then should a browser only display those pages correctly that use
100% W3C HTML? Firefox needs to handle some bad HTML if it wants to be
viable and a real-world app, just as your apps handle real-world users and
their stupid mistakes.
FWIW, I have converted almost completely to using Opera. The browsing is
faster, pages display correctly almost always, and there is no isssues of
crashing the browser when I have multiuple pages open.
"Trevor Best" <no****@besty.org.uk> wrote: if you're going to write a
web page, write it for Firefox, if another browser doesn't work properly
then it's the fault of the browser.
::if you're going to write an
:: Access FE, write it for Windows users, if a Mac/Linux user doesn't
understand it
:: then it's the fault of the user.
Darryl Kerkeslager | |
|
P: n/a
|
"Mike MacSween" <mi************************@btinternet.com> wrote in message
news:41*********************@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 | |
|
P: n/a
|
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" <mi************************@btinternet.com> wrote in message
news:41*********************@news.aaisp.net.uk... "Michael C" <mc*****@NOSPAMoptushome.com.au> wrote in message
news:uf**************@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 | |
|
P: n/a
|
"Michael C" <mc*****@NOSPAMoptushome.com.au> wrote in message
news:ef*************@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 | |
|
P: n/a
|
"Michael C" <mc*****@NOSPAMoptushome.com.au> wrote in message
news:uh**************@tk2msftngp13.phx.gbl... "Mike MacSween" <mi************************@btinternet.com> wrote in
message news:41*********************@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 | |
|
P: n/a
|
Lyle Fairfield wrote: Trevor Best <no****@besty.org.uk> wrote in
news:41**********************@news.zen.co.uk:
Lyle Fairfield wrote:
MDBs with ODBC connections might be as raddy. Since I haven't used
these I can't say which of the problems noted above occur in these
too. But I wouldn't go this route because I don't want to use ancient
technology.
I'd call it "proven" technology rather than ancient.
Like pushrod engines?
Not really as a twin cam 16V will beat it in most respects and won't
lose out on reliability, a better analogy would be the petrol or diesel
engine vs the newer LPG or electric both of which are not fully sorted
for everyday use by the masses.
--
This sig left intentionally blank | |
|
P: n/a
|
Darryl Kerkeslager wrote: Unfortunately, Firefox is buggy, slow, and doesn't handle multiple open web
pages well. The whole point of tabbed browsing is lost if you cant have
more than 5 complex web pages open at once. It's also a beautiful idea to
say that 'pages should be written for Firefox', but that to me is just as
short-sighted as saying 'pages should be written for IE'. You certainly
don't write your Access programs just to be used by only the most careful
users; why then should a browser only display those pages correctly that use
100% W3C HTML? Firefox needs to handle some bad HTML if it wants to be
viable and a real-world app, just as your apps handle real-world users and
their stupid mistakes.
What have users and their stupid mistsakes got to do with programming to
defined standards? I've not noticed any problems with tabbed browsing
although I confess I don't have that many tabs open as a lot of pages
tend to open a new window and to say it's buggy in the same post as onme
that mentions IE bwahahahahahahahahahahaha. At least the bugs in Firefox
won't won't destroy your PC.
FWIW, I have converted almost completely to using Opera. The browsing is
faster, pages display correctly almost always, and there is no isssues of
crashing the browser when I have multiuple pages open.
Not a freebie though is it? :-)
"Trevor Best" <no****@besty.org.uk> wrote:
if you're going to write a
web page, write it for Firefox, if another browser doesn't work properly
then it's the fault of the browser.
::if you're going to write an
:: Access FE, write it for Windows users, if a Mac/Linux user doesn't
understand it
:: then it's the fault of the user.
Complete crap, that is nothing remotely like what I said.
--
This sig left intentionally blank | |
|
P: n/a
|
Lyle Fairfield wrote: What's an HTA?
HTML Application
http://msdn.microsoft.com/workshop/a...taoverview.asp
There beautiful and easy! They require Internet Explorer!
Argggggghhhhhhhhh!
And XP SP2 has disabled them by default, says a lot for them.
--
This sig left intentionally blank | |
This discussion thread is closed Replies have been disabled for this discussion. | |  Question stats - viewed: 2502
- replies: 67
- date asked: Nov 13 '05
|
