If your app only runs locally, there is less of a concern for online malicious SQL injection, unless you suspect your local users could do it.  Access is traditionally used in local environments, so there is little safeguard for this, unlike more modern tools like Visual Studio, Power Apps, etc.  For instance, Power Apps doesn't even use SQL to run queries.  In Visual Studio, SQL string concatenation is disallowed, because that is often how SQL injection is done.

One way to prevent SQL injection is to avoid using string concatenation to form SQL statements.  E.g.:

     SELECT * FROM Table1 WHERE ID = " & UserEntry

Even a simple statement like this is not safe.  If a user enters this in a textbox on a form:

     123 OR True

The SQL becomes:

     SELECT * FROM Table1 WHERE ID = 123 OR True

which will LIST EVERYTHING in the table, because the user entry is mistakenly treated as part of the code.

To prevent this, you use a parameter query:

     SELECT * FROM Table1 WHERE ID = [UserEntry]

This way, [UserEntry] is always treated as a literal value, and is never confused as part of the code.

Mr. ChatGPT recommends using a "parameterized SQL query" to prevent SQL injection attacks.  I had never heard of this before, and could not find any videos or other docs on this site.  Does anyone else have experience with parameterized SQL queries?

This was sample code that ChatGPT provided, but I have to admit I am not following how this works.  Might be a good video idea ;-)

Details

Dim strSQL As String
Dim MyText As String
Dim Field1 As String
Dim Field2 As Integer
Dim Field3 As Date
Dim Field4 As Double
Dim Field5 As Long

' Assuming you have values for each field.
MyText = "This is a text with double quotes: ""Quoted Text""."
Field1 = "Value1"
Field2 = 42
Field3 = DateValue("2023-09-21")
Field4 = 3.14
Field5 = 12345

' Create a parameterized SQL query.
strSQL = "INSERT INTO MyTable (MyField, Field1, Field2, Field3, Field4, Field5) " & _
         "VALUES (?, ?, ?, ?, ?, ?)"

' Create a Command object and set the parameters.
Dim cmd As Object
Set cmd = CreateObject("ADODB.Command")
cmd.ActiveConnection = CurrentProject.Connection
cmd.CommandText = strSQL

' Add parameters for each field and specify their data types.
Dim param As Object

' MyField (assuming it's a string)
Set param = cmd.CreateParameter("Param1", adVarWChar, adParamInput, Len(MyText), MyText)
cmd.Parameters.Append param

' Field1 (assuming it's a string)
Set param = cmd.CreateParameter("Param2", adVarWChar, adParamInput, Len(Field1), Field1)
cmd.Parameters.Append param

' Field2 (assuming it's an integer)
Set param = cmd.CreateParameter("Param3", adInteger, adParamInput, , Field2)
cmd.Parameters.Append param

' Field3 (assuming it's a date)
Set param = cmd.CreateParameter("Param4", adDate, adParamInput, , Field3)
cmd.Parameters.Append param

' Field4 (assuming it's a double)
Set param = cmd.CreateParameter("Param5", adDouble, adParamInput, , Field4)
cmd.Parameters.Append param

' Field5 (assuming it's a long)
Set param = cmd.CreateParameter("Param6", adBigInt, adParamInput, , Field5)
cmd.Parameters.Append param

' Execute the query.
cmd.Execute

' Clean up.
Set cmd = Nothing

A "parameterized SQL query" is the same thing I mentioned in my earlier post, a parameter query, which this site should have videos for.  The code ChatGPT gave you is for non-Access environment.  In Access VBA, you use different code to form a parameter query, as shown in the picture below.

I haven't had much of a problem with this in Access. It's a BIG issue on websites. I've got this on my list for a future video topic. Thanks for the great explanation, Kevin.

An example use case that could fix into your training narratives could be something like this:

Image you have a data source that provides updated POCs names for customers the database.  Assume this data comes from an external system or a provider in an Excel file.  Also assume that it can provide you with a customerID, FirstNamePOC, MiddleNamePOC, and LastNamePOC.
One of the POCs is: Montgomery Scott, who goes by the name "Scotty".  The Excel lists the FirstName as:
     Montgomery "Scotty"
If a SQL UPDATE query tries to process this, the quote marks will cause the SQL to fail.  The solution would need to be able to find the escape character (the quote) and encapsulate it so that it is not interpreted by SQL as an end of string.

That would fail even there were no attempts at code injection.  Code injection would count on the SQL to *not fail*, but instead execute differently from what the developer intended.  Code injection would not need quotes, as shown in my example above, where the user enters "123 OR True" (no quotes) and ruins the SQL.  Preventing that would need a whole lot of coding, or replacing string concatenation with a parameterized SQL system.