Welcome to SPN

Register and Join the most happening forum of Sikh community & intellectuals from around the world.

Sign Up Now!

Hacking around with a prototype

Discussion in 'Information Technology' started by Mike Labosh, Jul 28, 2006.

  1. Mike Labosh

    Mike Labosh
    Expand Collapse
    Guest

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

    Similar Threads Forum Date
    Politics Hacking India's Voting Machines Breaking News Apr 30, 2010
    Islam Beautiful Mosques around the World.... Interfaith Dialogues Aug 24, 2012
    Nature 'Supermoon' Dominates Sunday Night Skyline Around The World Breaking News May 8, 2012
    Asia's shortage of brides stirs social upheaval around region Relationships Oct 31, 2011
    Religious Tolerance Ebbing around the World, Report Finds Interfaith Dialogues Aug 10, 2011

  3. David Browne

    David Browne
    Expand Collapse
    Guest

    "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
     
  4. John Vinson

    John Vinson
    Expand Collapse
    Guest

    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]
     
  5. Mike Labosh

    Mike Labosh
    Expand Collapse
    Guest

    > 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


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

    >
    >
     
  6. Mike Labosh

    Mike Labosh
    Expand Collapse
    Guest

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

    Tony Toews
    Expand Collapse
    Guest

    "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 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
     
  8. Tony Toews

    Tony Toews
    Expand Collapse
    Guest

    "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 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
     
  9. Bill Edwards

    Bill Edwards
    Expand Collapse
    Guest

    "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.
     
  10. jetro=)

    jetro=)
    Expand Collapse
    Guest

    >>> 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 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
    >
    >
    >
    >
     
  11. jetro=)

    jetro=)
    Expand Collapse
    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.

    "jetro=)" wrote:

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

    AverageUser
    Expand Collapse
    Guest

    I rated your posting as not helpful!!!!

    "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 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
    >
    >
    >
    >
     
  13. Tibor Karaszi

    Tibor Karaszi
    Expand Collapse
    Guest

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

    --
    Tibor Karaszi, SQL Server MVP
    http://www.karaszi.com/sqlserver/default.asp
    http://www.solidqualitylearning.com/


    "AverageUser" <AverageUser@discussions.microsoft.com> wrote in message
    news:98FF75C1-8E20-4283-AA02-86635FD69C3A@microsoft.com...
    >I rated your posting as not helpful!!!!
    >
    > "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 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
    >>
    >>
    >>
    >>
     
  14. David Browne

    David Browne
    Expand Collapse
    Guest

    "Mike Labosh" <mlabosh_at_hotmail.com> wrote in message
    news:Or0bgQ1jGHA.1260@TK2MSFTNGP05.phx.gbl...
    >> 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!"
    >


    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
     
  15. David Browne

    David Browne
    Expand Collapse
    Guest

    "Tony Toews" <ttoews@telusplanet.net> wrote in message
    news:l34v82drv8ahlagh0bhe3dcep1totnubg8@4ax.com...
    > "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?
    >


    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.


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


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


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


    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
     
  16. dbahooker@hotmail.com

    dbahooker@hotmail.com
    Expand Collapse
    Guest

    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


    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 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
     
  17. dbahooker@hotmail.com

    dbahooker@hotmail.com
    Expand Collapse
    Guest

    BILL

    {censored word, do not repeat.} YOU ADP ISNT BEING DISCONTINUED.

    MDB IS BEING DISCONTINUED {censored word, do not repeat.}TARD



    Bill Edwards wrote:
    > "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.
     

Share This Page