By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,657 Members | 1,760 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,657 IT Pros & Developers. It's quick & easy.

SQL Server Express: Anybody Using It?

P: n/a
I skimmed the MS spiel at http://msdn.microsoft.com/sql/express, and noted the
part about "all inside the Visual Studio 2005 environment".

Do the older SQL server tools for security and stored procedure editing work
too?
--
PeteCresswell
Feb 20 '06 #1
Share this Question
Share on Google+
42 Replies


P: n/a
I am using it.Access 2003 ADPs can do some editing of an SQL Express db
design, but not everything; TTBOMR table design is not modifiable with
Access 2003 ADPs; Stored Procedures are, but we are warned that they
are not. But the various .Net technologies come with a very nice
utility for editing tables, stored procedures etc in SQL Express; since
it's a lot slicker than the Access utility, I don't miss the Access
capability at all.
I don't know about security. I have noticed zero difference, but then,
I have't looked at this topic.

Feb 20 '06 #2

P: n/a
Per Lyle Fairfield:
But the various .Net technologies come with a very nice
utility for editing tables, stored procedures etc in SQL Express; since
it's a lot slicker than the Access utility, I don't miss the Access
capability at all.


So, if I install the .NET development environment on one of my boxes, I should
be good to go....

BTW: Can SQL Server Express be run on one machine and used by apps on another
machine? i.e. Could I offer it as a functional alternative solution to .MDB
based apps where 5-10 users share the same back end over a LAN connection?

If so, it would seem like the better path to take instead of using a .MDB as
long as the administrative part isn't too daunting for a regular LAN-type
person.
--
PeteCresswell
Feb 20 '06 #3

P: n/a
I haven't done this (used SQL Express on Machine A from Machine B on a
LAN (hmmmmmm .... maybe I have, but I'm away right now and can't
check).

Be advised that connecting to SQL Express after it is installed can be
challenging. MS didn't choose to make it useable out-of-the-box, so to
speak. Fortunately it's so challenging that there are multiple posts to
newsgroups about the problems that arise and solutions for them.

Feb 20 '06 #4

P: n/a
"Lyle Fairfield" <ly***********@aim.com> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com...
I haven't done this (used SQL Express on Machine A from Machine B on a
LAN (hmmmmmm .... maybe I have, but I'm away right now and can't
check).

Be advised that connecting to SQL Express after it is installed can be
challenging. MS didn't choose to make it useable out-of-the-box, so to
speak. Fortunately it's so challenging that there are multiple posts to
newsgroups about the problems that arise and solutions for them.

I did this a few months ago just to have a look around. The bit I remember
getting caught with was the deafult WinXP SP2 firewall which stopped me
connecting to the database. Although I spent over an hour looking at other
things before I worked that one out. Doh!
Feb 20 '06 #5

P: n/a
"Lyle Fairfield" <ly***********@aim.com> wrote
Be advised that connecting to SQL Express after it is installed can be
challenging. MS didn't choose to make it useable out-of-the-box, so to
speak.

Works fine for me:
------------------------------
Dim cnxn As ADODB.Connection
Set cnxn = New ADODB.Connection
cnxn.ConnectionTimeout = 1
cnxn.ConnectionString = "Provider=sqloledb;" & _
"Data Source=.\SQLEXPRESS;" & _
"Initial Catalog=mdfFileName;" & _
"Integrated Security=SSPI"
cnxn.Open
-------------------------------

I would also note that SQL Server Express without Visual Web Developer
Express is like Jet without Access.
--
Darryl Kerkeslager
Feb 20 '06 #6

P: n/a
Then
SQL Server Express with Visual Web Developer
Express is like Jet with Access?

Feb 20 '06 #7

P: n/a
Per Anthony England:
I did this a few months ago just to have a look around. The bit I remember
getting caught with was the deafult WinXP SP2 firewall which stopped me
connecting to the database. Although I spent over an hour looking at other
things before I worked that one out. Doh!


I've been nailed by my firewall (another brand...) a number to times just using
SQL Server Developer's Version/MSDE.

Can't remember how many times... but eventually it soaked in and I update the
firewall's list by habit now.
--
PeteCresswell
Feb 20 '06 #8

P: n/a
"Lyle Fairfield" <ly***********@aim.com> wrote
Then
SQL Server Express with Visual Web Developer
Express is like Jet with Access?


Um, no, not exactly .. bit of a logic error, there.

However, the following three (free) MS products, combined, offer more than
Access/Jet:

Visual Web Developer Express 2005
SQL Server 2005 Express
Visual Basic 2005 Express

- Development for a sever database and desktop database can be done
identically - no need to be concerned about having to upgrade/replace the
desktop app at some point

- The VB.Net language can be used for console, web, and database apps, a
slight improvement over VBScript, VBA, and VB (although VB.Net does not do
Office apps).

- Web development is integral, without ADP or ASP.

- performance of SQL Server vs. Jet - both are so fast on a single desktop,
that it doesn't even matter.

It would take someone who is an expert in both Access/Jet/VBA and
ADO.Net/SQL Server/VB.Net to truly compare the RAD power of both - but I
would say the combination of these three products (all currently free) have
so many strengths, that Access now has serious competition for the first
time for developers who want to work independently and develop great
standalone database products.

The last adverb for that sentence would be "quickly" - but I don't know
about that, and I'm not sure there are enough true experts in both to know.

Disclaimer: All of this is IMHO, is not intended to ignite flames, and is
based on as yet limited fiddling with the above three tools.
--
Darryl Kerkeslager
Feb 20 '06 #9

P: n/a
Darryl Kerkeslager wrote:
However, the following three (free) MS products, combined, offer more than
Access/Jet:

Visual Web Developer Express 2005
SQL Server 2005 Express
Visual Basic 2005 Express


I've done some of this; it's as fast or faster to develop than Access;
it's as powerful or more powerful than Access; it's far easier to
deploy than Access.
Access is over, done, finished, dead!

Feb 20 '06 #10

P: n/a
Per Lyle Fairfield:
I've done some of this; it's as fast or faster to develop than Access;
it's as powerful or more powerful than Access; it's far easier to
deploy than Access.


Can 10 different PC's concurrently connect their MS Access front ends to a
single instance of Access Express running on some other PC?
--
PeteCresswell
Feb 20 '06 #11

P: n/a
Access Express?

Feb 20 '06 #12

P: n/a
"(PeteCresswell)" <x@y.Invalid> wrote in
news:97********************************@4ax.com:
Per Anthony England:
I did this a few months ago just to have a look around. The bit I
remember getting caught with was the deafult WinXP SP2 firewall
which stopped me connecting to the database. Although I spent
over an hour looking at other things before I worked that one out.
Doh!


I've been nailed by my firewall (another brand...) a number to
times just using SQL Server Developer's Version/MSDE.

Can't remember how many times... but eventually it soaked in and I
update the firewall's list by habit now.


It would be better to change your SQL Server to use a nonstandard
port and unblock *that* port. Then, only exploits that scan all
ports would be able to attempt a connection to it. If you use
default ports, it's just an open invitation to nefarious interests.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Feb 20 '06 #13

P: n/a
"Darryl Kerkeslager" <ke*********@comcast.net> wrote in
news:UI******************************@comcast.com:
However, the following three (free) MS products, combined, offer
more than Access/Jet:

Visual Web Developer Express 2005
SQL Server 2005 Express
Visual Basic 2005 Express


And is the result hosted in a web browser?

If so, it just isn't comparable.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Feb 20 '06 #14

P: n/a
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote
And is the result hosted in a web browser?


Could be; doesn't have to be.

I don't have all the answers - I'm just looking into a lot of this and
trying it out, myself - but it does seem pretty promising.

You can write executables - no "runtime version" required.

I see no reason in the documentation why you shouldn't be able to use it
over a LAN (and since the documentation mentions concurrent users, I guess
that would logically follow).

I have 80 users connected to my Access db now - maybe 40 concurrent - could
I also do 40 concurrent users with SQL Server Express with the 1 GB RAM
limit - I have no idea.

I'm certainly not worried about the 4GB data file limit.

Can I develop software as quickly with .Net as with Access? Don't know that
either - but I will say that I have coded a heck of a lot of VBA in Access,
and Access isn't the magical RAD tool I once thought it was. So I'm willing
to give something else a shot.
--
Darryl Kerkeslager
Feb 20 '06 #15

P: n/a
Per Lyle Fairfield:

Oops.... SQL Server Express..
--
PeteCresswell
Feb 20 '06 #16

P: n/a
My Installed SQL SERVER Express returns
for
SELECT @@MAX_CONNECTIONS

32767

The SDK says that

@@MAX_CONNECTIONS

Returns the maximum number of simultaneous user connections allowed on
an instance of SQL Server. The number returned is not necessarily the
number currently configured

I believe that this number can be modified.

Feb 20 '06 #17

P: n/a
I wonder what this means, "hosted in a web browser". HTAs and DAPs are
hosted in Internet Explorer. That's clear. But as I see .NET (aspx)
applications, everything is done on the server; they send html (perhaps
xhtml) to the client's browser and they get data posted back, but
nothing is "run" on the client, So far in my testing they have worked
flawlessly on IE, NS, Firefox and K-Meleon.

Feb 21 '06 #18

P: n/a
Per Darryl Kerkeslager:
Can I develop software as quickly with .Net as with Access? Don't know that
either - but I will say that I have coded a heck of a lot of VBA in Access,
and Access isn't the magical RAD tool I once thought it was. So I'm willing
to give something else a shot.


My one experience doing the same, identical app in MS Access and VB6 resulted in
a 1:3 ratio of man hours. I did the Access version first, so probably got
something of a free ride on the VB6 version design-wise. Others have opined as
high as 1:5.

At least one guy has claimed to me that he can develop the same app either way
in the same number of man hours. I've got trouble with that one - if only
because of little things like creating/aligning labels for text boxes and the
extra code needed for auto-scrolling combo box drop downs.

Of the two apps that I wrote only to have somebody's IT department rewrite them
as net-centric, one was delivered by me for about 70k but cost over 3 mil to
have reproduced as net-centric.

The other was delivered by me for something under 250k over five years and
rewritten in 100% .NET against an Oracle DB. Last time I checked, it was
supposed to be almost ready for production and they'd spent over 23 mil on it.
With that one, there was an increase in functionality - but more like 30-40
percent than 1,000 percent.
--
PeteCresswell
Feb 21 '06 #19

P: n/a
>
Can I develop software as quickly with .Net as with Access? Don't know
that either - but I will say that I have coded a heck of a lot of VBA in
Access, and Access isn't the magical RAD tool I once thought it was. So
I'm willing to give something else a shot.


The new vb.net does a really incredible job of handling the "connection" to
the database. This something that ms-access has been better at then just
about everything else in the marketplace for years. So, data binding in the
new .net is really nice.

However, having to install a server based system. (that has to
startup/shutdown) when you application runs, and the lack of a integrated
reporting that ms-access has still makes ms-access a rad tool of choice.
Further, things like sub-forms, and even more incredible is continues forms
in ms-access...such as noted here:

http://www.members.shaw.ca/AlbertKal...icles/Grid.htm

Further, nothing as mentioned is stopping one from using the sql express as
the data engine. However, the last 3 copies (that is a LONG time) of office
has shipped with a free edition of sql server for use with ms-access. So,
the advent of sql express does not change this formula in a huge way (there
is no throttle on the new express..so, sure..it is better then the free
MSDE).

It still only takes one line of code to open a form..and sent it to a
particular invoice number in ms-access. Those other .net systems while
good...still are NOT in the genre of ms-access in terms of rad development.
And, they still don't have a integrated report writer that is close to
ms-access one....

FoxPro, FileMaker, Ms-access etc. all exist because a general purpose
programming system like vb.net can never really equal the abilities of
system DESIGNED for database data entry. I would not use ms-access to write
a pac man game...but vb.net would be good choice. And, it don't make sense
to write a CAD system in vb.net when you have AutoCAD. The right tool for
the right task is critical here.

As new technology rolls out, it is integrated into ms-access. When VB got
class objects...then ms-access got it. When ADO came out...ms-access got
ADO. When XML became all the rage....the last two versions of ms-access has
had xml features added. We have add-is for source code control. And, we even
now have a SOAP ad-in to consume web services.

If your application requirements go beyond a typical data entry application
(CRUD = create, read, update,delete), then ms-access might not be the best
choice. However, for most small business applications....even if you use sql
server...ms-access is still the best choice IMHO....

The only real reason why the new vb express + sql express can challenge
ms-access is because it is free..and ms-access is actually now a premium
priced product from ms....

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal


Feb 21 '06 #20

P: n/a
"Albert D. Kallal" <ka****@msn.com> wrote
However, having to install a server based system. (that has to
startup/shutdown) when you application runs, and the lack of a integrated
reporting that ms-access has still makes ms-access a rad tool of choice.
Further, things like sub-forms, and even more incredible is continues
forms
in ms-access...such as noted here:


Not sure what the problem is with the server-based system ... ?

I understand SQL Server Express is supposed to get the new SQL Reporting
tools as well ... but since I don't know how easy they are to use, I don't
know what to reply. I will agree, that the ease of use of Access Reports
will be hard to beat.

For me, though, I see a great benefit in doing Windows and web, PC and
server, in one language (VB.Net), one data model (ADO.Net), and one database
(SQL Server). Basically, I'm buying the Microsoft marketing
hook-line-and-sinker.

And, as an incidental note, there are a whole lot more jobs out there for
people with the above areas of knowledge than there are for Access/Jet/DAO.
This may not matter to those who have a secure living already carved out
with Access, but I don't.

--
Darryl Kerkeslager
Feb 21 '06 #21

P: n/a
> For me, though, I see a great benefit in doing Windows and web, PC and
server, in one language (VB.Net), one data model (ADO.Net), and one
database (SQL Server). Basically, I'm buying the Microsoft marketing
hook-line-and-sinker.


Well, actually, what they done is really incredible. Further, I been waiting
patiently for TEN YEARS to give me a server product that lets me write in a
decent language..and have the server run and consume that code. The fact
that I don't have to try and write really crap code in t-sql, and can now
use vb(net) to write my code for the server side is really a killer concept.
Why use a lousily server side language....it never made sense. My time
on systems like D3 and Universe taught me how nice it is to have a
really nice programming language on the server side (these are
mainframe systems, .but in their form to today, the database
programming language on these systems is now simply the server side coding
language).

So, sure..there is some marketing here..but golly, that .net platform is
really
nice..and the same system can be used to write code for sql server, or your
pda , or web services or next week for your desktop!!

This is much like the grand unified theory that
Einstein was looking for.........

While the whole .net genre was overhyped...the integration of all
technologies from sql server to the web to desktop to pda is now a reality.

People have not yet grasped how important this crossover system is called
..net is.
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com
http://www.members.shaw.ca/AlbertKallal
Feb 21 '06 #22

P: n/a
Per Darryl Kerkeslager:
For me, though, I see a great benefit in doing Windows and web, PC and
server, in one language (VB.Net), one data model (ADO.Net), and one database
(SQL Server). Basically, I'm buying the Microsoft marketing
hook-line-and-sinker.
I've been trying to - but when I ask myself what I *really* do, the answer comes
out something like "I deliver usable applications in a much shorter timeframe
than IT can and for substantially fewer dollars.". Given that, I'd need to
develop some kind of CRUD skeleton in .NET that I can clone/customize in some
reasonable approximation of the time it takes to turn out the same thing via MS
Access.

And, as an incidental note, there are a whole lot more jobs out there for
people with the above areas of knowledge than there are for Access/Jet/DAO.
This may not matter to those who have a secure living already carved out
with Access, but I don't.


I'd agree with that, but keep my eye on the ripples from Bangalore.
--
PeteCresswell
Feb 21 '06 #23

P: n/a
"Darryl Kerkeslager" <ke*********@comcast.net> wrote in
news:L_******************************@comcast.com:
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote
And is the result hosted in a web browser?
Could be; doesn't have to be.


How else would the application be run? An executable?
I don't have all the answers - I'm just looking into a lot of
this and
trying it out, myself - but it does seem pretty promising.
For browser-based applications, certainly.

As a replacement for Access, it's hopeless, seems to me -- it can't
come close.
You can write executables - no "runtime version" required.

I see no reason in the documentation why you shouldn't be able to
use it over a LAN (and since the documentation mentions concurrent
users, I guess that would logically follow).

I have 80 users connected to my Access db now - maybe 40
concurrent - could I also do 40 concurrent users with SQL Server
Express with the 1 GB RAM limit - I have no idea.

I'm certainly not worried about the 4GB data file limit.

Can I develop software as quickly with .Net as with Access? Don't
know that either - but I will say that I have coded a heck of a
lot of VBA in Access, and Access isn't the magical RAD tool I once
thought it was. So I'm willing to give something else a shot.


I think that people who never use the RAD tools in Access should
probably be looking at something else. I also think that there are
an awful lot of unnecessary unbound forms out there in Access apps,
and this is one of the reasons so many people end up with so much
code -- they aren't using Access for what it's good for.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Feb 21 '06 #24

P: n/a
"Darryl Kerkeslager" <ke*********@comcast.net> wrote in
news:5o********************@comcast.com:
"Albert D. Kallal" <ka****@msn.com> wrote
However, having to install a server based system. (that has to
startup/shutdown) when you application runs, and the lack of a
integrated reporting that ms-access has still makes ms-access a
rad tool of choice. Further, things like sub-forms, and even more
incredible is continues forms
in ms-access...such as noted here:
Not sure what the problem is with the server-based system ... ?


Well, you have two choices:

1. start up the SQL Server service at boot, OR

2. start it up on demand and then shut it down when finished.

For security and performance reasons, I'd certainly prefer the
latter.

Of course, I'm assuming here a single-user application, and in that
situation I just can't see the utility of a server db engine running
locally, except if your app must support both single users and
shared users.

[]
For me, though, I see a great benefit in doing Windows and web, PC
and server, in one language (VB.Net), one data model (ADO.Net),
and one database (SQL Server). Basically, I'm buying the
Microsoft marketing hook-line-and-sinker.
Well, if you're *doing* browser-based, web-hosted apps, that makes
sense.

For those of us who only do Access apps, it looks like the tail
wagging the dog -- implementation of features that do us absolutely
no good. This was the case with Access 2000's implementation of all
the server-friendly features, things that I didn't need then and
don't need now.

Frankly, I would have expected to be porting my apps to SQL Server
back ends by now, but Jet has held up just fine in terms of
performance and reliability. The cost of converting has been
ridiculously out of scale with the benefit that would have come from
it, and no one is more surprised than me that Access/Jet continues
to hold up under loads that I would have considered shading into the
realm of problematic.
And, as an incidental note, there are a whole lot more jobs out
there for people with the above areas of knowledge than there are
for Access/Jet/DAO. . . .
I think that's an artifact of buzzword-driven HR departments. Access
is the hidden development platform that the pros turn up their noses
at. Because of that, job descriptions seldom include Access as one
of the required skills.
This may not matter to those who have a secure living already
carved out with Access, but I don't.


I think the potential market for Access apps continues to grow.
There is no shortage of small businesses who need customized
database applications, and there never will be. For those
businesses, there is no purpose served by "webifying" those apps,
especially now with Windows Terminal Server deployment being so
incredibly easy (and built into Win2K3 Server). Without wide WTS
availability, the pressure to go browser-based would be pretty
severe, but WTS has made it possible to make plain old Access apps
available to anyohe anywhere, with the most minimal client-side
software installation (and with Windows PCs that are 3+ years old or
younger, no client software at all).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Feb 21 '06 #25

P: n/a
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote

How else would the application be run? An executable?

Yes.
For browser-based applications, certainly.

As a replacement for Access, it's hopeless, seems to me -- it can't
come close.
Again, I'm still learning about the software capabilities, so at the risk of
being misinformed ...

These data controls seem very similar in capability to Access (again, keep
in mind that I'm reading the docs, not actually using these controls yet):

http://msdn.microsoft.com/vstudio/to...icOverview.htm

I think that people who never use the RAD tools in Access should
probably be looking at something else. I also think that there are
an awful lot of unnecessary unbound forms out there in Access apps,
and this is one of the reasons so many people end up with so much
code -- they aren't using Access for what it's good for.


All my forms are bound ... there's still a lot of code ...

--

Darryl Kerkeslager
Feb 22 '06 #26

P: n/a
Darryl Kerkeslager wrote:
"David W. Fenton" <XX*******@dfenton.com.invalid> wrote

How else would the application be run? An executable?


Yes.
For browser-based applications, certainly.

As a replacement for Access, it's hopeless, seems to me -- it can't
come close.


Again, I'm still learning about the software capabilities, so at the
risk of being misinformed ...

These data controls seem very similar in capability to Access (again,
keep in mind that I'm reading the docs, not actually using these
controls yet):


Ah, there you go. Actually try them and then report back.

I spent an exploratory few weeks with visual studio and dot-net and the amount
of work required just to get a record displayed on a form was staggering.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Feb 22 '06 #27

P: n/a
With Visual Web Developer 2005 Express Edition (free) I dragged an
MS-SQL View onto a aspx page and voila ... it's there as a datagrid,
like a continuous form, paged, sortable ...each row select-able,
editable, delete-able ... time required ... about 5 seconds ...
alternate line formatting? ... another few seconds.

I'm learning ... and fooled around for the better part of a day with
styles, appearance, authentication and insert.

When I got those passable, I created a similar page for another view
.... time about 2 minutes; I simply changed my SQL string and my field
names and headers headers and my parameters.

Tomorrow (maybe!) I'm going to experiment (or i'm going to watch the
Canadian Curling Teams at the Olympics) with ListBoxes ... Totals ...
conditional formats like red for negatives ... other gnarly things ...
I expect I'll be baffled by some ... but once I solve them I'll be ...
well I think I MAY be ... much faster than developing in Access ... and
I've been developing in Access for a long, long time ... I think 1991
but I'm not sure Access was around in 1991.

And when I want someone in Slovenia to be able to work with this ... I
send them a site address, a username and a password ... and THAT's it
....

Yeah ... I know ... what about reports ... probably that's a March or
April investigation. Maybe reports will be the fatal flaw.

But right now I think Access is dead. When Office renewal time comes
I'll go to Corel ... Quattro Pro is fabulous ... I'll do my db stuff on
the web.
Access is, as Tiger Williams would say, "Done like Dinner!".

Feb 22 '06 #28

P: n/a
"Lyle Fairfield" <ly***********@aim.com> wrote
But right now I think Access is dead.
I disagree with that. But it is clear that most of the changes to Access
that the 'Softies have blogged are in end-user functionality.
I'll do my db stuff on the web.
You may have found good tools for web database stuff, but the web isn't an
appropriate venue for many kinds of application -- if they don't "break" the
capabilities we have now, but do enhance the user experience, Access'll be
around, and useful, for a long time.
Access is, as Tiger Williams would say, "Done
like Dinner!".


We shall see. If so, it's been a good ride, and a longer one that you get
with most software.

Larry Linson
Microsoft Access MVP
Feb 22 '06 #29

P: n/a
Lyle Fairfield wrote:
With Visual Web Developer 2005 Express Edition (free) I dragged an
MS-SQL View onto a aspx page and voila ... it's there as a datagrid,
like a continuous form, paged, sortable ...each row select-able,
editable, delete-able ... time required ... about 5 seconds ...
alternate line formatting? ... another few seconds.
With any version of access I can link to a SQL Server view and just like
that I've got a datagrid that I can page, scroll, sort, edit, each row
selectable. Time required maybe 30 seconds. Do I have an application?

Grids are cheap and easy. Almost no one would expose an Access datasheet to
a user and call it an "application", but make a grid appear in a web browser
and now it's a piece of magic.

Now give your user CheckBoxes for Yes/No fields, drop downs that show one
thing while storing another. Master/Detail interfaces or the equivalent
functionality of an OptionGroup frame. If these can be accomplished in a
few minutes time with VS/Dot-Net then I must admit that I simply could not
see it. Perhaps Visual Web Developer is quite different from full-blown
Visual Studio.
I'm learning ... and fooled around for the better part of a day with
styles, appearance, authentication and insert.
I do the same thing in my Ajax development. What would take a few minutes
in Access takes hours in a web environment and that doesn't even take into
account trying to make sure that the page works and looks correct in
anything besides Internet Explorer.
When I got those passable, I created a similar page for another view
... time about 2 minutes; I simply changed my SQL string and my field
names and headers headers and my parameters.

Tomorrow (maybe!) I'm going to experiment (or i'm going to watch the
Canadian Curling Teams at the Olympics) with ListBoxes ... Totals ...
conditional formats like red for negatives ... other gnarly things ...
I expect I'll be baffled by some ... but once I solve them I'll be ...
well I think I MAY be ... much faster than developing in Access ...
and I've been developing in Access for a long, long time ... I think
1991 but I'm not sure Access was around in 1991.


You'll likely have a ball and learn a lot of new stuff (who doesn't like
that?), but I doubt that you will ever approach the development speed that
you could with Access.

Our company is switching all new development from Access/Delphi/RPG to Web
apps using Ajax methods. I find it incredibly interesting and haven't been
this enthused about coming to work in ages. Will any of my users benefit
from this change? I extremely doubt it. Stuff I used to give them in
minutes now go into the queue and when I get to them it will likely take a
day or two for the easy stuff and a week or two for the more complicated
stuff.

Now, if I were independent and my wages depended on getting the job done as
quickly as possible so I can move onto the next one I most certainly would
use Access unless there was something (technical or political) that forced
me to do otherwise.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Feb 22 '06 #30

P: n/a
Rick Brandt wrote:
Now give your user CheckBoxes for Yes/No fields, drop downs that show one
thing while storing another.


Bit fields defaulted to Check Boxes. I did zip to achieve this
functionality. I haven't got to Drop Downs yet but I was encouraged
when I dragged a ListBox onto the page/grid and was able to enter the
bound field and data source (my terms not those used by Visual Studio).

Feb 22 '06 #31

P: n/a
"Lyle Fairfield" <ly***********@aim.com> wrote in
news:11**********************@g44g2000cwa.googlegr oups.com:
Yeah ... I know ... what about reports ... probably that's a March
or April investigation. Maybe reports will be the fatal flaw.


Do all these magically created web pages work in all the good web
browsers (that is, anything but Internet Explorer)? Or are they
built of IE-only code? And can the results be run on something other
than ASP.NET, which is proprietary to Microsoft, and doesn't run on
anything but Windows servers (which no one in their right mind
should be choosing for production, Internet-facing websites)?

Or does all this development with these super-duper tools tie you
down to Microsoft products on the server side?

I have not as yet had a client ask me to put their application on a
web site (they often ask if they can access it via the web, by which
they mean remotely, not actually in a web browser), and that can be
easily implemented with Windows Terminal Server.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Feb 23 '06 #32

P: n/a
"Larry Linson" <bo*****@localhost.not> wrote in
news:EKTKf.42479$6f2.821@trnddc02:
"Lyle Fairfield" <ly***********@aim.com> wrote
But right now I think Access is dead.


I disagree with that. But it is clear that most of the changes to
Access that the 'Softies have blogged are in end-user
functionality.


But is that not simply a result of the order in which they are going
through the functionality, starting with the new aspects of the user
interface (which will be, by definition, the end-user part of the
equation), and leading up to the developer features?
I'll do my db stuff on the web.


You may have found good tools for web database stuff, but the web
isn't an appropriate venue for many kinds of application -- if
they don't "break" the capabilities we have now, but do enhance
the user experience, Access'll be around, and useful, for a long
time.


My bet is that these web pages Lyle is creating use proprietary,
IE-only coding that won't run in any other browser, which makes it
completely unacceptable as far as I'm concerned, since IE is not an
acceptable browser for use by anyone (and IE7 isn't going to change
that -- the problems are too fundamental to the design of IE and
Windows).
Access is, as Tiger Williams would say, "Done
like Dinner!".


We shall see. If so, it's been a good ride, and a longer one that
you get with most software.


Many Access developers outgrow Access as their development platform
and move on. So, "done for Lyle" does not at all mean that it's no
longer a viable product serving a large and vital market. So far as
I can see, Microsoft seems to be investing quite a bit of effort
into making Access better, which suggests to me that they aren't
about to abandon it.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Feb 23 '06 #33

P: n/a
"Rick Brandt" <ri*********@hotmail.com> wrote in
news:sU*****************@newssvr12.news.prodigy.co m:
Lyle Fairfield wrote:
With Visual Web Developer 2005 Express Edition (free) I dragged
an MS-SQL View onto a aspx page and voila ... it's there as a
datagrid, like a continuous form, paged, sortable ...each row
select-able, editable, delete-able ... time required ... about 5
seconds ... alternate line formatting? ... another few seconds.
With any version of access I can link to a SQL Server view and
just like that I've got a datagrid that I can page, scroll, sort,
edit, each row selectable. Time required maybe 30 seconds. Do I
have an application?

Grids are cheap and easy. Almost no one would expose an Access
datasheet to a user and call it an "application", but make a grid
appear in a web browser and now it's a piece of magic.


Yes, grids are relatively trivial. I could knock out PHP code to do
the same thing in about 2 minutes, myself, with no drag and drop. It
wouldn't be beautiful, but it would display the contents of a data
table in tabular form.
Now give your user CheckBoxes for Yes/No fields, drop downs that
show one thing while storing another. Master/Detail interfaces or
the equivalent functionality of an OptionGroup frame. If these
can be accomplished in a few minutes time with VS/Dot-Net then I
must admit that I simply could not see it. Perhaps Visual Web
Developer is quite different from full-blown Visual Studio.
Well, it's possible now with AJAX to develop much richer client-side
user interfaces for use in a browser. But those are created by
extending the standard HTML form widgets with JavaScript extensions
and event handlers. My bet is that if the tools Lyle is raving about
are implementing these features, they are *not* doing it in a
cross-browser compliant way. Look at the Exchange Server 2003
Outlook Web Access feature -- it uses AJAX techniques, but in a way
that works completely differently on IE than in other browsers. The
full-featured UI is available only with IE.

Tying your app to such a poor browser is a big mistake, in my
opinion, and you're also tying yourself (with ASP.NET) to Microsoft
server products and Windows-based hosting, which is generally more
expensive and less common than Apache/Linux-based hosting.
I'm learning ... and fooled around for the better part of a day
with styles, appearance, authentication and insert.


I do the same thing in my Ajax development. What would take a few
minutes in Access takes hours in a web environment and that
doesn't even take into account trying to make sure that the page
works and looks correct in anything besides Internet Explorer.


Anyone with any sense starts writing their HTML/CSS/AJAX for Firefox
and then figures out what doesn't work right in IE and patches that
(IE has tons of terribly CSS incompatibilities, which MS has failed
to promise to fix in IE7).
When I got those passable, I created a similar page for another
view ... time about 2 minutes; I simply changed my SQL string and
my field names and headers headers and my parameters.

Tomorrow (maybe!) I'm going to experiment (or i'm going to watch
the Canadian Curling Teams at the Olympics) with ListBoxes ...
Totals ... conditional formats like red for negatives ... other
gnarly things ... I expect I'll be baffled by some ... but once I
solve them I'll be ... well I think I MAY be ... much faster than
developing in Access ... and I've been developing in Access for a
long, long time ... I think 1991 but I'm not sure Access was
around in 1991.


You'll likely have a ball and learn a lot of new stuff (who
doesn't like that?), but I doubt that you will ever approach the
development speed that you could with Access.


Because browser-based apps are stateless, they require more screens
than Access does to accomplish the same tasks. And the widgets, even
with AJAX, are never going to be as rich as those available even in
Access 2.
Our company is switching all new development from
Access/Delphi/RPG to Web apps using Ajax methods. I find it
incredibly interesting and haven't been this enthused about coming
to work in ages. Will any of my users benefit from this change?
I extremely doubt it. Stuff I used to give them in minutes now go
into the queue and when I get to them it will likely take a day or
two for the easy stuff and a week or two for the more complicated
stuff.
One of the things that's happening, though, is that the people who
do web development *do* find .NET to be very helpful, since it's far
more productive than the old methods, because the development
environment is so good (I hear). They are seeing large improvements
in productivity.

But they've never experienced Access-style RAD development, so they
don't realize how incredibly far they are from true quick
development of apps with a rich UI.
Now, if I were independent and my wages depended on getting the
job done as quickly as possible so I can move onto the next one I
most certainly would use Access unless there was something
(technical or political) that forced me to do otherwise.


I don't understand why people think web-oriented development
techniques can possibly replace the speed and richness of a desktop
application's UI, with native OS widgets and bound data (rather than
being stateless).

And, as Larry said, many apps don't belong on the Web, so you're
actually crippling their functionality and making them harder to use
by converting them to be hosted in a web browser. As you say, this
is a very user-hostile thing to do, and I don't understand why
people think it's a good idea.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Feb 23 '06 #34

P: n/a
David W. Fenton wrote:
My bet is that these web pages Lyle is creating use proprietary,
IE-only coding that won't run in any other browser, which makes it
completely unacceptable as far as I'm concerned, since IE is not an
acceptable browser for use by anyone (and IE7 isn't going to change
that -- the problems are too fundamental to the design of IE and
Windows).


No, I don't use IE except for things like Winodws Update.
I am testing my pages in Firefox, K-Meleon and Netscape.

Feb 23 '06 #35

P: n/a
David W. Fenton wrote:

My bet is that these web pages Lyle is creating use proprietary,
IE-only coding that won't run in any other browser, which makes it
completely unacceptable as far as I'm concerned, since IE is not an
acceptable browser for use by anyone (and IE7 isn't going to change
that -- the problems are too fundamental to the design of IE and
Windows).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/


David,

Visual Studio 2005 produces compliant HTML by default, at least in my
experience. Obviously the developer needs to deal with different
browsers, and the lack of standards compliance in IE is a definite
issue. But the built in controls provided by ASP.NET produce compliant
HTML, using VS 2005 and the .NET framework 2.0 (and the IDE flags bad
markup).

I'm not commenting on the time to develop required by these platforms
at all, just adressing that one issue.

--

Ed

Feb 23 '06 #36

P: n/a
I've done some DropDowns now; they're about the same as Access
PullDowns; of course, they'll get easier as I become familiar with
them.
They let me filter my DataGrid easily and very quickly.

Feb 23 '06 #37

P: n/a
"ed********@gmail.com" <ed********@gmail.com> wrote in
news:11**********************@f14g2000cwb.googlegr oups.com:
David W. Fenton wrote:

My bet is that these web pages Lyle is creating use proprietary,
IE-only coding that won't run in any other browser, which makes
it completely unacceptable as far as I'm concerned, since IE is
not an acceptable browser for use by anyone (and IE7 isn't going
to change that -- the problems are too fundamental to the design
of IE and Windows).
Visual Studio 2005 produces compliant HTML by default, at least in
my experience. . . .


But it's styled by CSS, no? And IE6 is the least CSS-compliant
current browser out there.

Secondly, there's JavaScript (or, if VS is really stupidly designed,
JScript or VBScript), which is not cross-compatible between IE and
other browsers if the IE-only document model is used.

If it were just pure HTML, then it wouldn't be very useful at all,
so I can only presume that people are getting excited about VS
producing something a lot more elaborate than plain old
garden-variety HTML, and that means client-side scripting with
CSS/CSS2.
. . . Obviously the developer needs to deal with different
browsers, and the lack of standards compliance in IE is a definite
issue. But the built in controls provided by ASP.NET produce
compliant HTML, using VS 2005 and the .NET framework 2.0 (and the
IDE flags bad markup).
Eh? How does the client side of an application delivered in a
browser depend on the .NET framework? That's even worse if it does.

As to the "built in controls" what does that mean? Does something
have to be downloaded, or are these predefined classes that your
code can use to get extended functionality from the standard widgets
plus DHTML?
I'm not commenting on the time to develop required by these
platforms at all, just adressing that one issue.


You haven't really said anything that convinces me that VS is
producing good cross-browser code. If it renders differently in IE
than in FireFox, then it's not properly compliant. Based on my
experience with Outlook Web Access in IE vs. other browsers, I'd be
very surprised if MS would sacrifice additional functionality just
so that the code was not IE-specific. It would go against the whole
organization of all MS product lines, which is to decommoditize
standards and force you to build into your apps dependencies on MS
technologies and products (unless you sacrifice functionality).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Feb 23 '06 #38

P: n/a
David

It's not dependent on IE;
It doesn't run in IE, or on the client at all for that matter;
There is no browser code (except the Client Script one might find in
any HTML page, but this has nothing to do with the ASP.Net
application);
It's identical in form and substance on five browsers that I have
obswerved;
It can be styled by CSS but it also has its own visual properties, so
this is optional;
Nothing has to be downloaded;
It's great, fast, simple and powerful.

Feb 23 '06 #39

P: n/a
David W. Fenton wrote:
"ed********@gmail.com" <ed********@gmail.com> wrote in
news:11**********************@f14g2000cwb.googlegr oups.com:
David W. Fenton wrote:

My bet is that these web pages Lyle is creating use proprietary,
IE-only coding that won't run in any other browser, which makes
it completely unacceptable as far as I'm concerned, since IE is
not an acceptable browser for use by anyone (and IE7 isn't going
to change that -- the problems are too fundamental to the design
of IE and Windows).
Visual Studio 2005 produces compliant HTML by default, at least in
my experience. . . .


But it's styled by CSS, no? And IE6 is the least CSS-compliant
current browser out there.

Secondly, there's JavaScript (or, if VS is really stupidly designed,
JScript or VBScript), which is not cross-compatible between IE and
other browsers if the IE-only document model is used.

If it were just pure HTML, then it wouldn't be very useful at all,
so I can only presume that people are getting excited about VS
producing something a lot more elaborate than plain old
garden-variety HTML, and that means client-side scripting with
CSS/CSS2.


It produces HTML and javascript. CSS is up to the developer/designer.
It works across browsers just fine, although it is subject to the same
browser incompatibilities as any other web development process is.
. . . Obviously the developer needs to deal with different
browsers, and the lack of standards compliance in IE is a definite
issue. But the built in controls provided by ASP.NET produce
compliant HTML, using VS 2005 and the .NET framework 2.0 (and the
IDE flags bad markup).


Eh? How does the client side of an application delivered in a
browser depend on the .NET framework? That's even worse if it does.

As to the "built in controls" what does that mean? Does something
have to be downloaded, or are these predefined classes that your
code can use to get extended functionality from the standard widgets
plus DHTML?


No downloads. I'm talking about built in server controls that are data
aware. So at design time you can bind data sources to controls (which
are very extensible), attach methods to button clicks and do other
RAD-like development tasks. When the page is actually requested by the
browser, standard HTML and Javascript is delivered to the browser.
Nothing MS-only.

It's not RAD like Access is RAD, but for a web developer it's a pretty
big advance.
I'm not commenting on the time to develop required by these
platforms at all, just adressing that one issue.


You haven't really said anything that convinces me that VS is
producing good cross-browser code. If it renders differently in IE
than in FireFox, then it's not properly compliant. Based on my
experience with Outlook Web Access in IE vs. other browsers, I'd be
very surprised if MS would sacrifice additional functionality just
so that the code was not IE-specific. It would go against the whole
organization of all MS product lines, which is to decommoditize
standards and force you to build into your apps dependencies on MS
technologies and products (unless you sacrifice functionality).


Yeah, I've used OWA as well, so I know what you mean. But the fact that
code renders differently in IE vs other browsers is not due to the
development tool. I could write my code in Notepad, and it could still
render differently in IE as opposed to Firefox.

Older MS development tools attempted to bring some RAD properties to
web development, but FrontPage (at least back in the day, I don't know
what it does now) and Visual Interdev produced heavily IE specific
code, not to mention lousy HTML.

Visual Studio 2003 was a lot better; it didn't produce compliant markup
by default, but it was somewhat better behaved with non IE browsers. VS
2005 is a big step forward, IMO, though. It really is pretty browser
neutral. It produces compliant markup by default. I can drop server
controls onto my page, wire up a data source, and get cross browser
HTML just like that.

I'm an old Access developer who gradually moved to web applications,
and to be honest I can see a fair amount of Access 'philosophy' in
ASP.NET. Along with a lot of other things, of course, I'm not saying
it's merely an attempt to bring RAD practices to wweb development. But
going from Access to classic ASP was a real shocker. When I started
using ASP.NET, it was much closer to Access-style development.

I don't mean to sell it. As I said, it's not RAD like Access is RAD,
and if you're not doing web apps it's irrelevant anyway. But it's a
good tool, IMO, and something that actually allows you to support
clients who are using any platform or browser, not only Windows and IE.

--

Ed

Feb 24 '06 #40

P: n/a
"ed********@gmail.com" <ed********@gmail.com> wrote in
news:11**********************@z34g2000cwc.googlegr oups.com:
It's not RAD like Access is RAD, but for a web developer it's a
pretty big advance.


Well, sure. No one is disputing that.

The question is whether it gets even close to Access's level of RAD.
It doesn't, and the only reason it's a big success with web
developers is that they haven't a clue what the standard is for RAD
because they think Access is a toy.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Feb 24 '06 #41

P: n/a
Oh no, It's quite RAD.
But I don't think there's anything to worry about; Access Developers
should have no difficulty at all shifting over unless they never
learned ADO in which case the ADO.Net model is likely to be a mystery.

Feb 24 '06 #42

P: n/a
It's Sunday so maybe a little truth in posting is in order here:

My opinions - findings - nothing in stone for sure:
1. Visual Web Developer 2005 Express (VWDE) is a great vehicle for me
to write my ASP-ADO Net apps;
2. VWDE's web controls are fast and great for flat file type tables;
3. I have not yet found anyway to have my pull downs start with the
selected value as the value of the field in my main table;
4. I have not yet found a way to set the selected day of the Calendar
Web Control to the value of a Date field in my main table.

Of course, it's quite possible that these "ways" exist and that I just
haven't been able to find them. It's also possible that they exist only
in the versions of Visual Web Developer 2005 that cost.

In the meantime, I can't do with VWDE what I can do with the old
ASP-ADO technologies, and certainly, it doesn't approach Access as a
RAD platform.

BTW, the Calendar control is, to my mind quite basic and disappointing.
The aspx web pages can take a long time for initial load. And I was
unable to use the Calendar Control without posting back to the server
every time I chose a date, causing, of course, the screen of flash and
be redrawn.

I'll state once again that all these problems may be due just to my
inexperience.

Feb 26 '06 #43

This discussion thread is closed

Replies have been disabled for this discussion.