[AccessD] End of an era

Paul Wolstenholme Paul.W at industrialcontrol.co.nz
Wed Mar 27 17:17:28 CDT 2024


Thanks everyone for the excellent advice!
I will let my customer know that that is a viable route to take.  I think
the person who does any such rewrite should ideally be the person who wants
to support it for the next decade or more - and that isn't me.
The physical plant is also likely to need significant capital if it is to
continue that long.  The parent group has other considerations on where to
spend its money - perhaps their Ukrainian plants or their nearby Russian
one rather than this almost forgotten corner of the world.

Rocky,
I've always considered my objective has been to "help my customers
succeed".  They contract me because they lack local technical abilities so
I automatically strive to provide them with technical foresight - whether
they ask for it or not.  It is me who keeps looking ahead, not so much my
customer.  They do listen but it might take a few annual budget cycles to
bear fruit.

Stephen,
Subtle signs in your website lead me to conclude that those in
countries outside your own are of no interest.
(And in the same vein my customer knows well the advantages of local
support!)

Paul Wolstenholme


On Thu, 28 Mar 2024 at 04:00, Daniel Waters <df.waters at outlook.com> wrote:

> Hi Paul,
>
> Windows Forms / SQL Server is probably a good choice.
>
> Several things to know:
>
> One developer can handle it.
>
> WinForms is by default a WAN app.
>
> The forms, for users, can be almost indistinguishable from Access, if you
> choose to make them that way.
>
> I am recommending WinForms in .NET Framework 4.8.  MS has explicitly
> stated that as long as there is a Windows OS, there shall be a .NET
> Framework 4.8.  They don't plan to add features but will do security and
> quality updates. Of course, you can use the same database you have now.
>
> IT may have problems with Access but they won't with WinForms.  They might
> want you to update WinForms to the latest .NET, but don't.  WinForms in the
> latest version of .NET (8?) is still not up to par with the .NET Framework
> 4.8, and they've been working on it for 5 years now.
>
> WinForms does not have a query designer.  But you can still use Access's
> query designer to design and test.  Then you'll need to copy the SQL text
> from the query designer into WinForms code.
>
> If you set up LinqToSQL you can have an easier time writing SQL
> statements.  For example, if you write a table name in the statement, you
> can type a period at the end of the table name which will display a list of
> the fields in that table.  If your table (A) has a 1-many relationship with
> another table (B), then B's name shows up at the end of the list of A's
> field names, and you can select B's name and again type a period to get all
> the fields in B.  there's more, and this helps greatly with typing errors
> in any SQL Statement.  Pretty Nice!
>
> While the forms in WinForms look the same, the properties and events work
> differently - and it will take some time to learn those.
>
> You can make custom controls for the forms.  This way if you decide to
> change how a control works throughout the application you only need to make
> the changes in one place in code.  If you go with WinForms, let me know and
> I can send you my procedure you can use and/or start with.
>
> Creating a report in a WinForms application is a different very different
> concept from Access.  You can create almost anything, but it can be a lot
> of work.
>
> The code module/classes that you'll need will probably have most of the
> same functionality.  I ended up rewriting the code by commenting all the
> code in an Access module/class then copying to an identically named
> module/class in WinForms.  Then in VB.NET I could uncomment the first and
> last lines of the module/class and all the variable definitions.  From
> there I could rewrite the code into VB.NET (or C#) using the commented
> code as my guideline.  That worked efficiently.
>
> In Visual Studio you can get an Extension which will quickly convert all
> the code in a project from VB.NET to C# and back again.  So, if you'd
> prefer VB.NET but your customer wants C# you can both have what you want.
>
> The Visual Studio Developer Interface is excellent and highly
> customizable.  And, it is another learning curve.
>
> I need to stress that before you give your client a time or cost estimate,
> find a small App that you made in Access and convert that to WinForms.
> That will let you provide your client with a reasonable conversion estimate
> for the larger App you've made for them.
>
> Good Luck!
> Dan
>
> -----Original Message-----
> From: AccessD <accessd-bounces+df.waters=outlook.com at databaseadvisors.com>
> On Behalf Of Paul Wolstenholme
> Sent: 26 March, 2024 15:54
> To: Access Developers discussion and problem solving <
> accessd at databaseadvisors.com>
> Subject: Re: [AccessD] End of an era
>
> Is there a preferred migration path for a multi-user system having a 100MB
> Access FE application and a SQL Server BE?  I've been pondering that one
> for about a decade already (the app is ~22 years old with about 15 users).
>
> Paul Wolstenholme
>
>
> On Wed, 27 Mar 2024 at 07:18, Rocky Smolin <rockysmolin2 at gmail.com> wrote:
>
> > I'm still doing Access dev, but only a few hours a week for legacy
> clients.
> > My skills became obsolete just as I was sliding into retirement.
> > Timing is everything...
> >
> > r
> >
> > On Sat, Mar 23, 2024 at 3:35 PM Ryan Wehler <wrwehler at gmail.com> wrote:
> >
> > > Company I work for sold. Acquiring company has their own FE/DB
> > > solution that is C#/PostgreSQL.
> > >
> > > Naturally some skills might carry over, but 20+ years of writing
> > > T-SQL
> > and
> > > Access is coming to an end.   Heck I'm not even sure at this point if
> > I'll
> > > be in any developmental role. So far it seems like I'll land in the
> > > IT team, but maybe more in a Sysadmin role.
> > >
> > > Time will tell...
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > https://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > https://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>


More information about the AccessD mailing list