我应该使用 pyodbc 还是 win32com 使用 python 在 Microsoft Access 数据库 (.accdb) 中填写预先存在的 forms？

Question

I wrote a python script that extracts strings from word documents. The goal is to then insert these strings into a pre-existing form in an Access database, save it, create a duplicate of the form, insert different strings from the next word document, save, repeat. The form already has all the fields I need, and it has buttons for 'save' and 'create duplicate.'

I'm having trouble figuring out how to insert strings into the Access form.

So far I've learned that there are at least two ways of doing this, using pyodbc or win32com.

I used code from the following links:

pyodbc - https://datatofish.com/how-to-connect-python-to-ms-access-database-using-pyodbc/

win32com - Write to MS Access table, python win32com

I solved the problem of connecting 64-bit python to 32-bit access, and I was able to connect to my accdb file using win32com and pyodbc, but that's as far as I got.

pyodbc:

import pyodbc

conn = pyodbc.connect(r'Driver={Microsoft Access Driver (*.mdb, *.accdb)};DBQ=C:\path\folder\my_database_file.accdb;')
cursor = conn.cursor()

win32com:

import win32com.client

# ADODB constants
adVarWChar = 202
adInteger = 3
adParamInput = 1

connection = win32com.client.Dispatch(r'ADODB.Connection')

DSN = (
    r'PROVIDER=Microsoft.ACE.OLEDB.12.0;'
    r'DATA SOURCE=C:\path\folder\my_database_file.accdb;'
    )

connection.Open(DSN)

cmd = win32com.client.Dispatch(r'ADODB.Command')
cmd.ActiveConnection = connection

Which approach is better/easier to work with, pyodbc or win32com?

Also, once I choose an approach, how do I continue? I'm having trouble finding documentation on how to fill out forms in Access using these methods. Most of what I find was on how to fill out tables in Access, and I'm not sure how to transcribe that code to work with forms instead, or where that code comes from in the first place.

I did not include the code that extracts strings from word documents, that part works fine, and isn't really part of the question, just background information.

Any advice or pointers in the right direction would be much appreciated.

Answer 1

First and foremost, MS Access forms and reports do not store any data but apply visual interactivity with table or query data at runtime.

Secondly, your question shows how MS Access is the multifaceted thing that is both a GUI application and a database. Because of this your two approaches ( win32com and pyodbc ) are somewhat distinctly different and partially overlapping. Generally, there are two ways to interact with this software:

Front-End

1. Simply use the installed Microsoft Office software, MSAccess.exe, with all enabled user interface features to design and use its objects: tables, queries, forms, reports, macros, and modules.

2. Through programming code, interface to the Microsoft Access object library via an external client such as Excel VBA, Python, or any other COM-connected language or API.

   In Python, using win32com allows you to access the GUI objects of MS Access which includes forms and reports and any other Access methods like DoCmd.TransferSpreadsheet or Application.ImportXML . To run queries you need to access the underlying database of the Access application object. Overall, this approach requires the full-fledged Office application, MSAccess.exe, installed on client machines.

Back-End

• Connect to the underlying database of the .accdb (or .mdb ) file such as with ODBC or OLEDB using practically any modern, general purpose language like Python with corresponding libraries.

  In Python, using pyodbc (or adodbapi ) only allows you to interact with the Jet/ACE database (Window.dll files). You cannot interact with any GUI objects including forms and reports but only tables and stored queries and only using SQL called by application layer here being Python. Overall, this approach does NOT require the full-fledged Office application, MSAccess.exe, installed on client machines.

---

With that said, for your specific needs, you may not need the longer, more extensive win32com front-end approach since Access forms are designed to enter/update/delete data in underlying tables. In other words, they are user-friendly means to data handling. Therefore, simply circumnavigate the user interface need and directly import your extracted Word data into the database table behind the form with pyodbc , a much simpler, back-end method.

Specifically, to answer your questions:

I wrote a Python script that extracts strings from Word documents. The goal is to then insert these strings into a pre-existing form in an Access database, save it, create a duplicate of the form, insert different strings from the next word document, save, repeat.

First, no one should duplicate the actual form object but the data. Instead, insert data into the data source behind the form using the cursor object and parameterization:

# APPEND QUERY WITH PARAMETERS
sql = """INSERT INTO myTableBehindmyForm (Field1, Field2, Field3, ...)
         VALUES (?, ?, ?, ...)
      """

# EXECUTE QUERY WITH TUPLE OF BINDED VALUES
cursor.execute(sql, (word_string1, wordstring2, wordstring3, ...))

The form already has all the fields I need, and it has buttons for 'save' and 'create duplicate. I'm having trouble figuring out how to insert strings into the Access form.

To save, simply commit above query and to duplicate, repeat the cursor.execute call:

# EXECUTE QUERY WITH TUPLE OF BINDED VALUES
cursor.execute(sql, (word_string1, wordstring2, wordstring3, ...))
conn.commit()


# EXECUTE QUERY WITH TUPLE OF BINDED VALUES
cursor.execute(sql, (word_string1, wordstring2, wordstring3, ...))
cursor.execute(sql, (word_string1, wordstring2, wordstring3, ...))
conn.commit()

Most of what I find was on how to fill out tables in Access, and I'm not sure how to transcribe that code to work with forms instead, or where that code comes from in the first place.

Again, no need to work with forms (data-less GUI objects) but simply the tables behind forms. Therefore, go with pyodbc or any compliant MS Access and Python DB-API to handle your data needs.