Multiprocessing relies on pickling to communicate objects between processes. The pyodbc connection and cursor objects can not be pickled.

>>> cPickle.dumps(aCursor)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.5/copy_reg.py", line 69, in _reduce_ex
    raise TypeError, "can't pickle %s objects" % base.__name__
TypeError: can't pickle Cursor objects
>>> cPickle.dumps(dbHandle)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.5/copy_reg.py", line 69, in _reduce_ex
    raise TypeError, "can't pickle %s objects" % base.__name__
TypeError: can't pickle Connection objects

"It puts items in the work_queue", what items? Is it possible the cursor object is getting passed as well?

I was able to recreate the issue using pypyodbc, while the same code seems to work fine with pyodbc. One possible workaround for pypyodbc might be to convert the results to a list of dictionary objects and then serialize that:

import pickle, pypyodbc
connection_string = (
    r"Driver={SQL Server Native Client 10.0};"
    r"Server=(local)\SQLEXPRESS;"
    r"Database=myDb;"
    r"Trusted_connection=yes;"
)
connection = pypyodbc.connect(connection_string)
cur = connection.cursor()
cur.execute("SELECT * FROM Donors")

column_names = [x[0] for x in cur.description]
query_list = [dict(zip(column_names, row)) for row in cur.fetchall()]

with open(r'C:\Users\Gord\Desktop\query_result', 'wb') as f:
    pickle.dump(query_list, f)
cur.close()
connection.close()

So you have a binary file containing a pickled object. A hex dump of the file looks like this:

00000000: 8004 9515 0000 0000 0000 007d 9428 8c03  ...........}.(..
00000010: 666f 6f94 4b01 8c03 6261 7294 4b02 752e  foo.K...bar.K.u.

You can save the object to a binary column, then read it back and unpickle it via pickle.loads like so:

import pyodbc
import pickle

conn_str = (
    r'DRIVER=ODBC Driver 17 for SQL Server;'
    r'SERVER=.\SQLEXPRESS;'
    r'DATABASE=myDb;'
    r'Trusted_Connection=yes;'
)
cnxn = pyodbc.connect(conn_str, autocommit=True)
crsr = cnxn.cursor()
crsr.execute("CREATE TABLE #test (id INT PRIMARY KEY, pkl VARBINARY(max))")

# read pre-pickled object from file and save to table
with open(r'C:\Users\Gord\Desktop\data.pickle', 'rb') as f:
    sql = "INSERT INTO #test (id, pkl) VALUES (?, ?)"
    params = (1, f.read())
    crsr.execute(sql, params)

# read it back from database and unpickle it
pickled_data = crsr.execute("SELECT pkl FROM #test WHERE id=1").fetchval()
unpickled_object = pickle.loads(pickled_data)

print(unpickled_object)
# {'foo': 1, 'bar': 2}

Here is what ended up working (thanks to @Gord Thompson for getting me going in the right direction):

1. Using escaped parametrization -- according to pyodbc standard -- rather than Python's .format(). We ended up changing the query to something like:

q = "UPDATE table \
    SET serializedModel = CONVERT(VARBINARY(MAX), ?) \
    WHERE IDa = CONVERT(uniqueidentifier, ?) AND \
            IDb = CONVERT(uniqueidentifier, ?) AND \
            IDc = CONVERT(uniqueidentifier, ?)"

args = (RF_serialized,
        "x",
        "y",
        "z")

cursor.execute(q, args)
cnxn.commit()

2. Using CONVERT(uniqueidentifier, ?) rather than trying to put in special characters for strings (e.g. \') because SQL Server treats GUIDs/unique identifiers as a datatype.
3. I had a couple of extra queries hanging around from running tests/troubleshooting and I think an extra .execute() on one of them -- that totally messed with the query I was actually trying to fix.