Home/ Questions/Q 8975357
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-15T18:51:31+00:00

I’m working in a environment with a very poorly managed legacy Paradox database system.

  • 0

I’m working in a environment with a very poorly managed legacy Paradox database system. (I’m not the administrator.) I’ve been messing around with using pyodbc to interact with our tables, and the basic functionality seems to work. Here’s some (working) test code:

import pyodbc

LOCATION = "C:\test"

cnxn = pyodbc.connect(r"Driver={{Microsoft Paradox Driver (*.db )\}};DriverID=538;Fil=Paradox 5.X;DefaultDir={0};Dbq={0};CollatingSequence=ASCII;".format(LOCATION), autocommit=True, readonly=True)
cursor = cnxn.cursor()
cursor.execute("select last, first from test")
row = cursor.fetchone()
print row

The problem is that most of our important tables are going to be open in someone’s Paradox GUI at pretty much all times. I get this error whenever I try to do a select from one of those tables:

pyodbc.Error: ('HY000', "[HY000] [Microsoft][ODBC Paradox Driver] Could not lock 
table 'test'; currently in use by user '(unknown)' on machine '(unknown)'. (-1304) 
(SQLExecDirectW)")

This is, obviously, because pyodbc tries to lock the table when cursor.execute() is called on it. This behavior makes perfect sense, since cursor.execute() runs arbitary SQL code and could change the table.

However, Paradox itself (through its gui) seems to handle multiple users fine. It only gives you similar errors if you try to restructure the table while people are using it.

Is there any way I can get pyodbc to use some sort of read-only mode, such that it doesn’t have to lock the table when I’m just doing select and such? Or is locking a fundamental part of how it works that I’m not going to be able to get around?

Solutions that would use other modules are also totally fine.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Ok, I finally figured it out.

    Apparently, odbc dislikes Paradox tables which have no primary key. You cannot update tables with no primary key under any circumstances, and you cannot read from tables with no primary key unless you are the only user trying to access that table.

    Unrelatedly, you get essentially the same error messages from password-protected tables if you don’t supply a password.

    So I was testing my script on two different tables, one of which has both a password and a primary key, and one of which had neither. I assumed the error messages had the same root cause, but it was actually two different problems, with different solutions.

    There still seems to be no way to get access to tables without primary keys if they are open in someone’s GUI, but that’s a smaller issue.

    • 0