sql server clients: 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

[quoted text, click to view]

How so?

[quoted text, click to view]

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

[quoted text, click to view]

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.

[quoted text, click to view]

Maybe. I've not got too much experience with the SQL server groups. I wasn't
sure which the best were.

Cheers, Mike

[quoted text, click to view]

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.

[quoted text, click to view]

Use a longer cable.

--
David G.

[quoted text, click to view]

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.

[quoted text, click to view]

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.

[quoted text, click to view]

I haven't got a clue what you're talking about. My question was perfectly
clear.

[quoted text, click to view]

So you mean MDBs or ADPs. Bound or unbound forms? OLE-DB or ODBC connection?

Infact just like I asked.

Mike

"Mike MacSween" <mike.macsween.zerospamplease@btinternet.com> wrote in
message news:419a6b0c$0$218$5a6aecb4@news.aaisp.net.uk...
[quoted text, click to view]

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.

[quoted text, click to view]

You probably didn't need to cross post this to so many groups, it really
defeats the purpose of having groups.

Michael

[quoted text, click to view]

I'm looking for quick. Both in terms of user experience and developement
times.

Is Access dirty? Tell me why.

[quoted text, click to view]

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?

[quoted text, click to view]

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.

[quoted text, click to view]

Getting the job done is my aim!

Thanks, Mike

[quoted text, click to view]

LOL, very good David.

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...
[quoted text, click to view]

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.

"Mike MacSween" <mike.macsween.zerospamplease@btinternet.com> wrote in
message news:419a78b5$0$221$5a6aecb4@news.aaisp.net.uk...
[quoted text, click to view]

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.

[quoted text, click to view]

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

"Mike MacSween" <mike.macsween.zerospamplease@btinternet.com> wrote in
message news:419a6b0c$0$218$5a6aecb4@news.aaisp.net.uk...
[quoted text, click to view]

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.

[quoted text, click to view]

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?

[quoted text, click to view]

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.

[quoted text, click to view]

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.

[quoted text, click to view]

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,

[quoted text, click to view]

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.

[quoted text, click to view]

Not sure if it was my id, ego or super-ego doing the typing.

[quoted text, click to view]

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.

[quoted text, click to view]

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.

[quoted text, click to view]

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.

[quoted text, click to view]

Why?

[quoted text, click to view]

Oh good, that's a real recommendation.

[quoted text, click to view]

how better?

Micky

[quoted text, click to view]

So were they MDB front ends or ADP front ends? I know about Access as a back
end

[quoted text, click to view]

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

[quoted text, click to view]

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.

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...

[quoted text, click to view]

[quoted text, click to view]

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

[quoted text, click to view]

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

[quoted text, click to view]

Personally I dislike using web pages, but I'd rather use a web page than an
app written in access :-)

[quoted text, click to view]

Of course, SQL Server is a database only!!! This is like saying my Lada is
faster than a tree. :-)

[quoted text, click to view]

Barely.

Michael

"Mike MacSween" <mike.macsween.zerospamplease@btinternet.com> wrote in
message news:419af009$0$214$5a6aecb4@news.aaisp.net.uk...
[quoted text, click to view]

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."

[quoted text, click to view]

For the keyboard shortcuts you are right.

[quoted text, click to view]

I don't see the problem, it just depends how you write the web page.

[quoted text, click to view]

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.

[quoted text, click to view]

That's a programming feature.

[quoted text, click to view]

Another programming feature but asp.net does have this.

[quoted text, click to view]

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.

[quoted text, click to view]

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

(some groups dropped from the X-Post as my ISP doesn't carry them, how
many sqlserver groups are there FFS?)

[quoted text, click to view]

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:

--

[quoted text, click to view]

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.

[quoted text, click to view]

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? :-)

[quoted text, click to view]

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?

[quoted text, click to view]

The fastest way to do something is rarely the best.

[quoted text, click to view]

In too many ways to list. :-)

Michael

[quoted text, click to view]

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 :-)

[quoted text, click to view]

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

[quoted text, click to view]

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

[quoted text, click to view]

Thanks

Maybe time to look at .net and c#.

Cheers, Mike

[quoted text, click to view]

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.

[quoted text, click to view]

[quoted text, click to view]

I recall some comments along the lines of the transition from VB6 to C# is easier
because the syntax is quite different. Thus more difficult to get confused about
similar syntax between VB6 and VB.Net.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at