Brian
Tue Jun 22 02:26:52 CDT 2004
This is a multi-part message in MIME format.
------=_NextPart_000_001C_01C45800.61122580
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Been there done that. Access is not an unstable platform if written =
properly. The issues I had were that it was not written as should be. =
Little error handling, no commenting and work around out the ..... The =
other issue is that you either had to have access or use the redist =
package. This was fine until you had more than one application, one that =
took 97, one that took 2000 and the problems just kept coming. I have =
been in both worlds. Access is easier to deploy rapidly, reports are =
fast and easy and database is easy to work with. .Net is more robust and =
growth, IMHO, is easier to work with. .Net is also a full blown program =
vb or c#. If you need real secure database or web then to me there is =
no question.
We decided to convert the whole app to .Net. At first, we used an access =
backend but moved up to SQL. The problems with fixes, data corruption =
and instability went away. It is an application now that gets used.=20
--=20
Brian P. Hammer
"aualias" <aualias@newsgroups.nospam> wrote in message =
news:u4pzMF9VEHA.2544@TK2MSFTNGP10.phx.gbl...
I have a small-medium sized Access application that is poorly written. =
My
choices are to either rewrite large parts of the Access app so that it
functions reasonably well, or to convert the whole thing to .NET.
Not being an Access developer, the .NET approach seems most natural, =
but I
want to do the right thing for the client (even if I end up giving =
away the
contract). I posted on the Access forum and got the impression that =
my
fears about Access being an unstable piece of junk were unfounded, and =
that
most of the things that need to be done in this type of application =
could be
done quickly and easily in Access and the rest could be coded as one =
would
do in any other environment (just have to give up the "free" things =
that
Access provides).
Does anyone have any experience with this type of conversion? I would =
be
interested in your thoughts.
Alfredo
------=_NextPart_000_001C_01C45800.61122580
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial>Been there done that. Access is not an =
unstable=20
platform if written properly. The issues I had were that it was not =
written as=20
should be. Little error handling, no commenting and work around out the=20
..... The other issue is that you either had to have access or use =
the=20
redist package. This was fine until you had more than one application, =
one that=20
took 97, one that took 2000 and the problems just kept coming. I have =
been in=20
both worlds. Access is easier to deploy rapidly, reports are fast and =
easy and=20
database is easy to work with. .Net is more robust and growth, IMHO, is =
easier=20
to work with. .Net is also a full blown program vb or c#. If =
you=20
need real secure database or web then to me there is no =
question.</FONT></DIV>
<DIV><FONT face=3DArial></FONT> </DIV>
<DIV><FONT face=3DArial>We decided to convert the whole app to .Net. At =
first, we=20
used an access backend but moved up to SQL. The problems with fixes, =
data=20
corruption and instability went away. It is an application now that gets =
used.=20
</FONT></DIV>
<DIV><BR>-- <BR>Brian P. Hammer</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"aualias" <<A=20
=
href=3D"mailto:aualias@newsgroups.nospam">aualias@newsgroups.nospam</A>&g=
t;=20
wrote in message <A=20
=
href=3D"news:u4pzMF9VEHA.2544@TK2MSFTNGP10.phx.gbl">news:u4pzMF9VEHA.2544=
@TK2MSFTNGP10.phx.gbl</A>...</DIV>I=20
have a small-medium sized Access application that is poorly =
written. =20
My<BR>choices are to either rewrite large parts of the Access app so =
that=20
it<BR>functions reasonably well, or to convert the whole thing to=20
.NET.<BR><BR>Not being an Access developer, the .NET approach seems =
most=20
natural, but I<BR>want to do the right thing for the client (even if I =
end up=20
giving away the<BR>contract). I posted on the Access forum and =
got the=20
impression that my<BR>fears about Access being an unstable piece of =
junk were=20
unfounded, and that<BR>most of the things that need to be done in this =
type of=20
application could be<BR>done quickly and easily in Access and the rest =
could=20
be coded as one would<BR>do in any other environment (just have to =
give up the=20
"free" things that<BR>Access provides).<BR><BR>Does anyone have any =
experience=20
with this type of conversion? I would be<BR>interested in your=20
thoughts.<BR><BR>Alfredo<BR><BR><BR><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_001C_01C45800.61122580--