Hacking around with a prototype

[Mike Labosh]

DO NOT say "Visio".

This is not for a client project of any kind. I just want to experiment.

If my experiment is successful, or leads me in a direction that whaps me on
the head and says, "SQL Server", then it will go into SQL Server.
Otherwise, I will build the thing in Access. WHY? Because it's easier to
slap something together in Access. And even if the experiment succeeds, and
goes into "production", it will only be for only my personal use.

So, I am asking for opinions: SQL Server with a .NET front end? or SQL
Server with an Access adp front end? Or just all in Access?

Please state your opinions for each technology, along with two paragraphs of
WHY you choose that technology.

Remember, this is not for work, or for a client. But it will accumulate
real data.
--


Peace & happy computing,

Mike Labosh, MCSD MCT
Owner, vbSensei.Com

"Escriba coda ergo sum." -- vbSensei

 

[David Browne]

DO NOT say "Visio".

This is not for a client project of any kind. I just want to experiment.

If my experiment is successful, or leads me in a direction that whaps me
on the head and says, "SQL Server", then it will go into SQL Server.
Otherwise, I will build the thing in Access. WHY? Because it's easier to
slap something together in Access. And even if the experiment succeeds,
and goes into "production", it will only be for only my personal use.

So, I am asking for opinions: SQL Server with a .NET front end? or SQL
Server with an Access adp front end? Or just all in Access?

Please state your opinions for each technology, along with two paragraphs
of WHY you choose that technology.

Remember, this is not for work, or for a client. But it will accumulate
real data.

SQL Server with a .NET front end. SQL Server 2005 with .NET 2.0 Winforms
beats Access across the board. With data binding and Visual Studio
integration, you have a development environment that is as easy to use as
Access, but without the limitations, without VB Script, etc. Also you
should invest your time in technologies that are strategic to your career
and understanding. Your deep and intimate knoledge of Access ADP projects
is unlikely to come in handy later. And you should prototype projects and
do little projects in big technologies. 100% of the code and skills you use
in a .NET 2.0 Winforms, SQL Server implementation are applicable to "real"
projects.

David

 

[John Vinson]

So, I am asking for opinions: SQL Server with a .NET front end? or SQL
Server with an Access adp front end? Or just all in Access?

Or my choice for such projects, SQL/Server for data storage and an
Access database (NOT an adp) frontend. Just another option for your
mix...

John W. Vinson[MVP]

 

[Mike Labosh]

SQL Server with a .NET front end. SQL Server 2005 with .NET 2.0 Winforms

beats Access across the board. With data binding and Visual Studio
integration, you have a development environment that is as easy to use as
Access, but without the limitations, without VB Script, etc. Also you
should invest your time in technologies that are strategic to your career
and understanding. Your deep and intimate knoledge of Access ADP projects
is unlikely to come in handy later. And you should prototype projects and
do little projects in big technologies. 100% of the code and skills you
use in a .NET 2.0 Winforms, SQL Server implementation are applicable to
"real" projects.

David

If you are the "David" that I think you are, then you should already know
that I am a badass at Access, SQL Server and .NET.

That aside,

I take issue on your thoughts about data binding. The way Access does
databinding is sweet and free. The way Visual Studio.NET does databinding
is expensive, braindead, sloppy, retarded and dangerous. vbSensei will
*never* use data binding in .NET. It is idiotic at best, satanic and
abyssmal at worst. I prefer a .sln solution with either a WIN32 or Web App
against a Database project, all inside the same solution, but at this point
in the design phase, seems a bit much.

What I mean is, that while "real architects" design a system with Visio, I
as a developer am in easier territory with the cheesy way Access does
things, just so I can drag-n-drop something together to prove if it will
work. (No offence to you Access folks)

Perhaps I did not phrase my question clearly enough: I want to prototype a
system that will not be largely scaled. Its purpose is for my wife (the
*totally* non-tech user) to be able to click some buttons when someone calls
her on the phone -- , say, I'm out teaching a class, and in the mean time
some MCT broker calls her on the phone and asks, "Can Mike do the xyz
class?" She should be able to click a combo box or button and figure it
out, and then say, "Nope he's booked all up", or, "Yeah, hea's available on
the week of abc". So the thing will only be used by one (perhaps two)
persons.

I could do this in Access. I am just asking for design opinions. Maybe
from people that have done this before.

My own gut instinct as a middle-tier developer is that this should be
implemented as an SQL Server database with MTS / COM+ EnterpriseServices
components that feed a web page......... but the practical person in me
says, "Dude, that's stupid. You have two users, for crying out loud!"

--


Peace & happy computing,

Mike Labosh, MCSD MCT
Owner, vbSensei.Com

"Escriba coda ergo sum." -- vbSensei

 

[Mike Labosh]

Or my choice for such projects, SQL/Server for data storage and an

Access database (NOT an adp) frontend. Just another option for your
mix...

Thank you so much for your inclusion of another exponent inside my design
matrix.

GRBNF!

I will be assured to help the people in your group with the most bizarrely
abstract code snips the world has ever seen.

J/K

But thanks for your input. I will now return to my glass of wine [DAMN
WAIT! SPILLAGE!] and another napkin with a pen.
--


Peace & happy computing,

Mike Labosh, MCSD MCT
Owner, vbSensei.Com

"Escriba coda ergo sum." -- vbSensei

 

[Tony Toews]

SQL Server with a .NET front end. SQL Server 2005 with .NET 2.0 Winforms
beats Access across the board. With data binding and Visual Studio
integration, you have a development environment that is as easy to use as
Access,

How is Net 2.0 Winforms as easy to use as Access?

but without the limitations, without VB Script, etc.

What limitations? Especially that are applicable for one user or
even less than, say, 25 or 50 users?

VB Script? I was unaware that Access used VB Script?

so you
should invest your time in technologies that are strategic to your career
and understanding. Your deep and intimate knoledge of Access ADP projects
is unlikely to come in handy later. And you should prototype projects and
do little projects in big technologies. 100% of the code and skills you use
in a .NET 2.0 Winforms, SQL Server implementation are applicable to "real"
projects.

<snort> Every week or two I turn down emailed requests for me to work
in Access. I guess I'm just not doing real work.

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
http://www.granite.ab.ca/accsmstr.htm

 

[Tony Toews]

Perhaps I did not phrase my question clearly enough: I want to prototype a
system that will not be largely scaled. Its purpose is for my wife (the
*totally* non-tech user) to be able to click some buttons when someone calls
her on the phone -- , say, I'm out teaching a class, and in the mean time
some MCT broker calls her on the phone and asks, "Can Mike do the xyz
class?" She should be able to click a combo box or button and figure it
out, and then say, "Nope he's booked all up", or, "Yeah, hea's available on
the week of abc". So the thing will only be used by one (perhaps two)
persons.

I could do this in Access. I am just asking for design opinions. Maybe
from people that have done this before.

My own gut instinct as a middle-tier developer is that this should be
implemented as an SQL Server database with MTS / COM+ EnterpriseServices
components that feed a web page......... but the practical person in me
says, "Dude, that's stupid. You have two users, for crying out loud!"

<shrug> I have a client with 25 users in Access all day long. It
works and works well.

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
http://www.granite.ab.ca/accsmstr.htm

 

[Bill Edwards]

DO NOT say "Visio".

This is not for a client project of any kind. I just want to experiment.

If my experiment is successful, or leads me in a direction that whaps me
on the head and says, "SQL Server", then it will go into SQL Server.
Otherwise, I will build the thing in Access. WHY? Because it's easier to
slap something together in Access. And even if the experiment succeeds,
and goes into "production", it will only be for only my personal use.

So, I am asking for opinions: SQL Server with a .NET front end? or SQL
Server with an Access adp front end? Or just all in Access?

Please state your opinions for each technology, along with two paragraphs
of WHY you choose that technology.

Remember, this is not for work, or for a client. But it will accumulate
real data.
--


Peace & happy computing,

Mike Labosh, MCSD MCT
Owner, vbSensei.Com

"Escriba coda ergo sum." -- vbSensei

Options =
1. SQL Server back end and .Net front end -- why? Seems to be overkill.
2. SQL Server back end and Access mdb front end -- given your level of
expertise could be blown off pretty quickly, probably almost as quickly as
option 4
3. SQL Server and Access adp -- hesitant to go this way because of
discontinuation of MS support/recommendation for adp's.
4. Jet and Access mdb -- given your level of expertise could be blown off
pretty quickly using a single mdb and then splitting into FE and BE when
done.

Usage = Single user

Assumption: Database will be split into a front and a back end if using Jet
and SQL Server.

Given above: There is a relatively low risk of database corruption if using
Jet.
If even this low risk of database corruption with JET is unacceptable then
use a SQL or MSDE backend.

If for some reason the design of the application would benefit from triggers
and stored procedures (I would assume from the limited information given
that this is not critical) then use SQL or MSDE backend

If the physical size of the database is too much for Jet or MSDE (again
given the information I am assuming this is not the case) then use SQL
Server backend.

Given your level of Access and SQL Server expertise, the choices seem to be
Jet and Access or SQL Server/MSDE and Access mdb. with the choice really
resting on answers to:
1. Can you live with the possibility of corruption if you use Jet. Chances
are this is a minimal risk given the usage.
2. Usefulness that triggers and stored procedures might give you development
using SQL/MSDE backend. Again, given the usage these are probably not that
critical.
3. Physical quantity of data. Will probably be OK with Jet or MSDE.

Final Answer: Jet and Access.

 

[Guest]

try to use telnet

 

[Guest]

try to link you project to telnet we already try it but dont try it if you
have an existing law in hacking, coz we do not have a law.

 

[Guest]

I rated your posting as not helpful!!!!

 

[Tibor Karaszi]

How can you rate a question as helpful or not? Isn't the purpose of the rating system to rate
*replies*?

 

[David Browne]

If you are the "David" that I think you are, then you should already know
that I am a badass at Access, SQL Server and .NET.

That aside,

I take issue on your thoughts about data binding. The way Access does
databinding is sweet and free. The way Visual Studio.NET does databinding
is expensive, braindead, sloppy, retarded and dangerous. vbSensei will
*never* use data binding in .NET. It is idiotic at best, satanic and
abyssmal at worst. I prefer a .sln solution with either a WIN32 or Web
App against a Database project, all inside the same solution, but at this
point in the design phase, seems a bit much.

What I mean is, that while "real architects" design a system with Visio, I
as a developer am in easier territory with the cheesy way Access does
things, just so I can drag-n-drop something together to prove if it will
work. (No offence to you Access folks)

Perhaps I did not phrase my question clearly enough: I want to prototype
a system that will not be largely scaled. Its purpose is for my wife (the
*totally* non-tech user) to be able to click some buttons when someone
calls her on the phone -- , say, I'm out teaching a class, and in the mean
time some MCT broker calls her on the phone and asks, "Can Mike do the xyz
class?" She should be able to click a combo box or button and figure it
out, and then say, "Nope he's booked all up", or, "Yeah, hea's available
on the week of abc". So the thing will only be used by one (perhaps two)
persons.

I could do this in Access. I am just asking for design opinions. Maybe
from people that have done this before.

My own gut instinct as a middle-tier developer is that this should be
implemented as an SQL Server database with MTS / COM+ EnterpriseServices
components that feed a web page......... but the practical person in me
says, "Dude, that's stupid. You have two users, for crying out loud!"

My point is that

1) Picking the "right tool" for each job by focusing just on the
requirements for the job at hand is shortsighted. You should solve problems
with as small a toolkit as is reasonably possible. Since Access is not
suitable for some things, and .NET and SQL are suitable for most things,
that should be your default choice.

2) If you feel that the "right way" to implement this applicaiton in .NET
and SQL server requires too much work or complexity, I would suggest that
that indicates a defect in your understanding or skillset around .NET and
SQL Server. Knowing how to implement highly complex mission critical
applications is not a proper subset of knowing how to quickly and easilly
implement small applications. Highly complex enterprise applciations are
not always better. And with Web Services, SOA and SQL Server backends
available to encapsulate the complexity of enterprise applications, cheap,
easy quick client applications are highly usefull.

If you prefer not to use .NET databinding, look into other ways to quickly
slap applications together in .NET.

David

 

[David Browne]

How is Net 2.0 Winforms as easy to use as Access?

It think it's close. There's certianly not as big a difference as there was
between VB6 and Access, or .NET 1.1 and access.

It probably depends on the complexity of the project. But many Access
projects I have worked on would have been easier to implement in .NET 2.0
WinForms. And the deployment story is much better: ClickOnce.

In Access easy things are very easy, and hard things are very hard. In .NET
it's much more balanced. Easy things may be a bit harder, but hard things
are much easier (if that makes sense). Features like Layout containers,
visual inheritence, web services, OO languages VB.NET and C#, and the .NET
Framework really help with non-trivial applications. If you have
complicated layout, lots of code, or 3rd party ActiveX controls, or are
accessing Win32 functions, etc Access development gets hard fast.

What limitations? Especially that are applicable for one user or
even less than, say, 25 or 50 users?

VB Script? I was unaware that Access used VB Script?

I misspoke. It uses VBA. Still a crappy language compared to VB.NET.

<snort> Every week or two I turn down emailed requests for me to work
in Access. I guess I'm just not doing real work.

I wasn't meaning to diss Access here. I was refering to the OP's real
projects: his day job stuff. He uses .NET and SQL Server for a living, and
these are his strategic technologies. If you use Access, more power to you,
and you wouldn't have a dilemma here.

David

 

[dbahooker]

Mike;

Rather than starting off in MDB and re-writing it in SQL.. you should
just be using Access Data Projects.

I am faster at ADP than anyone else around here is on MDB.

So i can build it right-- the first time-- instead of building it
twice.

Do it nice or do it twice.

-Aaron

 

[dbahooker]

Tony;

you are full of shit buddy.

your users aren't happy.. i mean; it takes 30 seconds to open their
apps!!!
I met one on usenet the other day; they were complaining about this guy
named tony that made all these crappy; slow mdb apps

-Aaron

 

[dbahooker]

BILL

**** YOU ADP ISNT BEING DISCONTINUED.

MDB IS BEING DISCONTINUED ****TARD