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...
> 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.
> 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...
> 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.
> 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...
> 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 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.
>
> I haven't got a clue what you're talking about. My question was
> perfectly clear.
>
> 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
