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"Mike Labosh" <mlabosh_at_hotmail.com> wrote in message
news:u4kcQu0jGHA.4660@.TK2MSFTNGP03.phx.gbl...
> 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|||On Tue, 13 Jun 2006 20:43:31 -0400, "Mike Labosh"
<mlabosh_at_hotmail.com> wrote:
>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]|||> 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 w
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
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:O4ejo30jGHA.4816@.TK2MSFTNGP04.phx.gbl...
> "Mike Labosh" <mlabosh_at_hotmail.com> wrote in message
> news:u4kcQu0jGHA.4660@.TK2MSFTNGP03.phx.gbl...
>|||> 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|||"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote:
>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 us
e
>in a .NET 2.0 Winforms, SQL Server implementation are applicable to "real"
>projects.
<snort> Every w
or two I turn down emailed requests for me to workin 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|||"Mike Labosh" <mlabosh_at_hotmail.com> wrote:
>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 call
s
>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 w
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|||"Mike Labosh" <mlabosh_at_hotmail.com> wrote in message
news:u4kcQu0jGHA.4660@.TK2MSFTNGP03.phx.gbl...
> 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.|||>>> try to use telnet
"Mike Labosh" wrote:
> 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 o
n
> 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, a
nd
> 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
>
>|||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.
"jetro=)" wrote:
> "Mike Labosh" wrote:
>
No comments:
Post a Comment