I.T. Discussion Community!
-Collapse +Expand
Paradox
Search Paradox Group:

Advanced
-Collapse +Expand Paradox To/From
To/FromCODEGuides
-Collapse +Expand Paradox Store
PRESTWOODSTORE

Prestwood eMagazine

August Edition
Subscribe now! It's Free!
Enter your email:

   ► MB LobbyCorel Paradox / ObjectPAL Coding BoardParadox to/from Other Data Sources Topic   Print This     

Problem when running exe from inside Paradox

Problem when running exe from inside Paradox in Paradox to/from Other Data Sources topic (part of our Corel Paradox / ObjectPAL Coding group).

Quick Search: Problem   running   Paradox   Problem when   Problem when running   exe inside  
iiii
-- USA

We work with Paradox 9. We must run a small application .net to upload several tables dBase IV to a Web site. When we tried to run the application from within Paradox, appears the following error message : " System.Data.Odbc.OdbcException: ERROR [HY000] [Microsoft][Controlador ODBC dBase] Error no esperado desde el controlador de la base de datos externa [Expected no error from the driver of the external database] (15877) ."

If it closes Paradox, the application runs perfectly.

LocalShare is true and our code is as follows:

var
tcAux                                      tCursor
sesionSincro                            session
dataBaseSincro                       database
app                                         application
endVar
 
[Optional for test
if NOT sesionSincro.open("sincroS")then
errorShow() RETURN
endIf
 
sesionSincro.addALias("AliasSincro", "Standard", pathDBF)
 
if NOT dataBaseSincro.open("AliasSincro", sesionSincro) then
errorShow() RETURN 
endIf
 
if NOT tcAux.open("imgup.DBF", dataBaseSincro)then
errorShow() RETURN 
endIf
]
 
if NOT tcAux.open("imgup.DBF") then
errorShow() RETURN 
endIf
... 
tcAux.close()
 
[Optional for test
dataBaseSincro.close()
sesionSincro.close()
]
 
app.minimize()
 
if NOT execute("C:\\appDotNet.exe", true) then
errorShow()
endIf
 
app.maximize()

What could be happening?


Thanks

 Posted 11 years ago (Thread Starter)
Comment Quote
About iiii -Collapse +Expand
Visit Profile
Approved member.
Member subscribes to this thread with a verified email.

Post ID #13171, 4 replies
Thread Started 12/16/2008 6:11:40 AM
View Counter=4592
Last Reply Posted 12/23/2008 8:29:22 PM)
Location=-- USA 
Joined=11 years ago   MB Posts=8  
AIBreveleri

Apparently Paradox is not releasing every lock on every dBase-IV table. If the DotNet application uses an ODBC driver that respects BDE locks, it will encounter an unexpected error.

Here are some ways to avoid leaving locks without intention:

Do not declare application, session, or database variables unless you are sure you need them. If you don't know whether you need them, you don't need them.

Do not place explicit locks via ObjectPAL statements lock() and lockRecord() unless you are sure you need them. You rarely need explicit locks unless you are changing linked data in multiple tables in a shared database.

Make sure that all the tcursors used on the dBase-IV tables are closed before executing the DotNet application. If your Paradox application is complex, this can be tedious, and is a common opportinuty for error.

I use this utility to examine the locks placed by the BDE:

http://home.comcast.net/~j.breveleri/lockwise.html

-Al.

 Posted 11 years ago
Comment Quote
About AIBreveleri -Collapse +Expand
Visit Profile
Approved member.
Member subscribes to this thread with a verified email.

Post ID #13176 (Level 1.1)  Reply to 13171
Thread Started 12/17/2008 5:06:13 PM
Location= 
Joined=18 years ago   MB Posts=286   KB Comments=8  
AIBreveleri

Suggestions:

(1) 'Cliente.exe' may be locking a private directory. Make sure it is not the one that :PRIV: points to.

Many database applications, especially in a managed-code environment, will lock a private directory even when it doesn't seem to be needed.

(2) Try executing a Paradox program with just the one line
execute(pathExe + "Cliente.exe", true, ExeShowNormal)

Paradox always begins by making an entry in the 'PDOXUSRS.NET' file, even before opening anything. If this entry is interfering with the ODBC dBase driver, then 'Cliente.exe' will fail even if Paradox has not touched 'propup.dbf'.

-Al.

 Posted 11 years ago
Comment Quote
About AIBreveleri -Collapse +Expand
Visit Profile
Approved member.
Member subscribes to this thread with a verified email.

Post ID #13178 (Level 1.2)  Reply to 13171
Reply Posted 12/23/2008 10:30:13 AM
Location= 
Joined=18 years ago   MB Posts=286   KB Comments=8  
iiii
-- USA
Quote:
Originally Posted by A. I. Breveleri

Apparently Paradox is not releasing every lock on every dBase-IV table. If the DotNet application uses an ODBC driver that respects BDE locks, it will encounter an unexpected error.

Here are some ways to avoid leaving locks without intention:

Do not declare application, session, or database variables unless you are sure you need them. If you don't know whether you need them, you don't need them.

Do not place explicit locks via ObjectPAL statements lock() and lockRecord() unless you are sure you need them. You rarely need explicit locks unless you are changing linked data in multiple tables in a shared database.

Make sure that all the tcursors used on the dBase-IV tables are closed before executing the DotNet application. If your Paradox application is complex, this can be tedious, and is a common opportinuty for error.

I use this utility to examine the locks placed by the BDE:

http://home.comcast.net/~j.breveleri/lockwise.html

-Al.

Al, thank you for your attention.

The tests were made as simply as possible. The only goal was to see if it was possible to run the DotNet application from inside Paradox.

Immediately after opening Paradox, we ran a macro of 3 lines of code to open and immediately close down one of the dBase tables, before running the DotNet application from Paradox. It was tested with localShare and AUTO ODBC false and true. The declaration of application, session, or database variables were made just to see if the problem was resolved.

 

This is the initial code:

tcAux.open(pathDBF + "propup.DBF")

tcAux.close()

execute(pathExe + "Cliente.exe", true, ExeShowNormal)

 

..and these are the display informations of LockWise

Paradox Off

 1         2          4          0         1CCE2020000                      00:00:25

 0                     BDE    0001    Esteban                       ----

 1                     BDE    0001    Esteban                       ----

 2

 

Paradox On

 2         3          4          0         1CCCE2020000                      00:00:30

 0                     BDE    0001    Esteban                       ----

 1         3          BDE    0001    Esteban                       ----       00:00:30

 2

 

1          2          4          0         1CCCE2020000                      00:04:16

0          2          BDE    0001    Esteban                       ----       00:04:16

1                      BDE    0001    Esteban                       ----

2

 

There is not an recent archive of PDOXUSRS.LCK

GE

 Posted 11 years ago (Thread Starter)
Comment Quote
About iiii -Collapse +Expand
Visit Profile
Approved member.
Member subscribes to this thread with a verified email.

Post ID #13177 (Level 1.3)  Reply to 13171
Reply Posted 12/19/2008 11:32:31 AM
Location=-- USA 
Joined=11 years ago   MB Posts=8  
Most Recent Post
iiii
-- USA
Quote:
Originally Posted by A. I. Breveleri

Suggestions:

(1) 'Cliente.exe' may be locking a private directory. Make sure it is not the one that :PRIV: points to.

Many database applications, especially in a managed-code environment, will lock a private directory even when it doesn't seem to be needed.

(2) Try executing a Paradox program with just the one line
execute(pathExe + "Cliente.exe", true, ExeShowNormal)

Paradox always begins by making an entry in the 'PDOXUSRS.NET' file, even before opening anything. If this entry is interfering with the ODBC dBase driver, then 'Cliente.exe' will fail even if Paradox has not touched 'propup.dbf'.

-Al.

I followed his advice and the DotNet application was executed perfectly. The problem only occurs when a table is opened. It is as if something in the BDE remains open and interferes with the ODBC driver.


Thanks again.

GE

 Posted 11 years ago (Thread Starter)
Comment Quote
About iiii -Collapse +Expand
Visit Profile
Approved member.
Member subscribes to this thread with a verified email.

Post ID #13179 (Level 1.4)  Reply to 13171
Reply Posted 12/23/2008 8:29:22 PM
Location=-- USA 
Joined=11 years ago   MB Posts=8  

Revive Thread!

Add a comment to revive this old thread and make this archived thread more useful.

Write a Comment...
Full Editor
...
Sign in...

If you are a member, Sign In. Or, you can Create a Free account now.


Anonymous Post (text-only, no HTML):

Enter your name and security key.

Your Name:
Security key = P1251A1
Enter key:
Icon: A Post    Thread    Idea    Important!    Cool    Sad    No    Yes    Includes a Link...   
Thread #13171 Counter
4592
Since 12/16/2008
Follow PrestwoodBoards on: 


©1995-2019 PrestwoodBoards  [Security & Privacy]
Professional IT Services: Coding | Websites | Computer Tech