Not a newbie, think of me as old school...

A short, practical companion for an old‑school QBasic programmer looking at Visual Basic and Access (references: @cllawrencecl2, @Tekmaven, @camelNotation, @samaru).

Three realistic ways forward, depending on goals:

• Keep writing QBasic‑style programs: use a QB‑compatible compiler/interpreter that runs on modern Windows. This preserves the original flow and syntax so little or no rewriting is required.
• Stay in the Access world: use VBA (the language inside Access) for form/report driven database apps. VBA feels familiar but runs inside Access and is best for data‑centric utilities.
• Move to Visual Basic under Visual Studio (for Windows apps): expect a different model (IDE + designer, event‑driven UI, modules/classes and stricter compile‑time checks). Porting will usually mean rethinking structure rather than a line‑by‑line copy.

Small example showing the surface differences (QBasic style vs a modern VB console):

' QBasic-ish
PRINT "Enter your name:"
INPUT name$
PRINT "Hello "; name$

' VB.NET console
Module Program
    Sub Main()
        Console.Write("Enter your name: ")
        Dim name As String = Console.ReadLine()
        Console.WriteLine("Hello " & name)
    End Sub
End Module

Practical checklist for a clean migration:

• Break long, linear code into Subs/Functions or classes.
• Remove GOTOs; use loops and structured control.
• Declare variable types explicitly and enable strict checking in the IDE to catch bugs early.
• Use the Form designer for UI work; avoid trying to "print to screen" like old console apps unless a console app is intended.
• For Access solutions, keep business logic in modular VBA where possible; consider moving to VB/.NET + a real RDBMS when scale or multi‑user access becomes important.

@Tekmaven started the right conversation; @samaru and @camelNotation’s exchange about typing points toward the practical step of enabling explicit/strict declarations early in learning the newer tools.