Main   Products   Offshore Outsourcing   Customers   Partners   ContactUs  
JDBC Databases
  HXTT Access v5.2
 
  Buy Now
  Support
  Download
  Document
  FAQ
  HXTT Cobol v2.1
  HXTT DBF v5.2
  HXTT Excel v4.2
  HXTT Paradox v5.2
  HXTT Text(CSV) v5.2
  HXTT XML v1.2
Offshore Outsourcing
Oracle Data Import/Export
DB2 Data Import/Export
Sybase Data Import/Export
Free Resources
  Firewall Tunneling
  Search Indexing Robot
  Conditional Compilation
  Password Recovery for MS Access
  Password Recovery for Corel Paradox
  Checksum Tool for MD5
  Character Set Converter
  Pyramid - Poker of ZYH
   
   
   
Hongxin Technology & Trade Ltd. of Xiangtan City (abbr, HXTT)

HXTT ACCESS
Strange behaviour after committing a transaction
Juan Escobar
2008-01-30 12:40:46.0
We are accessing to MsAccess through HXTT driver in Java and OTL driver in C++. The use case we are trying to do is:

Commit data in C++ side and then query (simple select statements) some data in Java. We query for data just committed in C++. Everything runs in the same process. Java invokes a native method by means of JNI in order to access to C++. The problem is that we have a couple of queries:

- select A from TableA: which returns 'true'.
- select A, B, C from TableA: which returns that A is 'false'.

Both queries are executed in the same transaction. When I try to debug the code, it worked fine and A is 'true' in both cases. I tried to put a 10 seconds-sleep but it did not worked when the application runs normally (without debugging).

Any idea?
Re:Strange behaviour after committing a transaction
HXTT Support
2008-01-30 17:56:50.0
HXTT Access can't do concurrent update with OTL driver because they're using different lock mechanism. You can try delayedClose=0 connection property to let HXTT Access to see that modification.
Re:Re:Strange behaviour after committing a transaction
Juan Escobar
2008-01-31 02:43:12.0
Yeah!

It worked fine. Thanks so much. I am having problems with views:
- I don't know how to create them
- If I use a mdb file with views already created, I cannot query them.

Where can I found information about this? I've been looking at previous entries in Support but I did not find anything useful for this.

PS: Thanks for your quick reply.
Re:Re:Re:Strange behaviour after committing a transaction
Juan Escobar
2008-01-31 04:03:08.0
Note: Actually my mdb has a lot of "Queries" (in the MSAccess jargon).
Re:Re:Re:Re:Strange behaviour after committing a transaction
HXTT Support
2008-01-31 06:02:17.0
>I am having problems with views:
>Note: Actually my mdb has a lot of "Queries" (in the MSAccess jargon).
>- I don't know how to create them
HXTT Access supports VIEW(QUERY of MS ACCESS), Linked Table to other Access databases, and most simple stored procedures (select, insert, update, and delete). It doesn't support to create VIEW sql, but it supports "select * from aViewName;".

>If I use a mdb file with views already created, I cannot query them.
What's your sql? If HXTT Access doesn't throw parse exception, then it should understand your VIEWs.
Re:Re:Re:Re:Re:Strange behaviour after committing a transaction
Juan Escobar
2008-01-31 07:09:20.0
Query: select * from VSECTORHASSITELATITUDE;

Where VSECTORHASSITELATITUDE is an existing QUERY in MS ACCESS.

This is the error I get:
Failed to find table VSECTORHASSITELATITUDE in database base_access.2
Re:Re:Re:Re:Re:Re:Strange behaviour after committing a transaction
HXTT Support
2008-01-31 20:30:45.0
Please zip and send us such a mdb sample, which needn't too much test data rows.
Re:Re:Re:Re:Re:Re:Re:Strange behaviour after committing a transaction
Juan Escobar
2008-02-06 07:03:46.0
Testing with delayedClose=0 was causing a serious performance degradation. We identified the problem came from querying to Views. After looking at what the process was doing, we found this:

at java.io.WinNTFileSystem.getLastModifiedTime(Native Method)
at java.io.File.lastModified(Unknown Source)
at com.hxtt.concurrent.a0.else(Unknown Source)
at com.hxtt.sql.access.a8.a(Unknown Source)
at com.hxtt.sql.access.a8.a(Unknown Source)
at com.hxtt.sql.access.a8.a(Unknown Source)
at com.hxtt.sql.access.j.if(Unknown Source)
- locked <0x2357da00> (a com.hxtt.sql.access.j)
at com.hxtt.sql.access.j.if(Unknown Source)
at com.hxtt.sql.access.j.a(Unknown Source)
at com.hxtt.sql.access.a2.a(Unknown Source)
- locked <0x238b8588> (a com.hxtt.sql.access.a2)
at com.hxtt.sql.o.a(Unknown Source)
at com.hxtt.sql.w.a(Unknown Source)
at com.hxtt.sql.b0.for(Unknown Source)
at com.hxtt.sql.b0.a(Unknown Source)
at com.hxtt.sql.de.a(Unknown Source)
at com.hxtt.sql.de.a(Unknown Source)
at com.hxtt.sql.de.a(Unknown Source)
at com.hxtt.sql.de.a(Unknown Source)
at com.hxtt.sql.cw.new(Unknown Source)
- locked <0x238b8378> (a com.hxtt.sql.cw)
at com.hxtt.sql.cw.next(Unknown Source)
at com.hxtt.sql.cw.i(Unknown Source)
at com.hxtt.sql.cd.a(Unknown Source)
at com.hxtt.concurrent.x.a(Unknown Source)
at com.hxtt.sql.s.a(Unknown Source)
at com.hxtt.sql.access.r.a(Unknown Source)
at com.hxtt.sql.bm.if(Unknown Source)
at com.hxtt.sql.de.a(Unknown Source)
at com.hxtt.sql.de.a(Unknown Source)
at com.hxtt.sql.bm.a(Unknown Source)
at com.hxtt.sql.dg.(Unknown Source)
at com.hxtt.sql.ef.(Unknown Source)
at com.hxtt.sql.bm.prepareCall(Unknown Source)
at com.hxtt.sql.bm.prepareCall(Unknown Source)
at com.hxtt.sql.bm.prepareCall(Unknown Source)
at com.hxtt.sql.b4.(Unknown Source)
at com.hxtt.sql.access.l.do(Unknown Source)
at com.hxtt.sql.access.l.a(Unknown Source)
at com.hxtt.sql.access.ao.a(Unknown Source)
at com.hxtt.concurrent.x.a(Unknown Source)
at com.hxtt.sql.access.a2.a(Unknown Source)
at com.hxtt.sql.access.r.a(Unknown Source)
at com.hxtt.sql.bm.if(Unknown Source)
at com.hxtt.sql.de.a(Unknown Source)
at com.hxtt.sql.de.a(Unknown Source)
at com.hxtt.sql.bm.a(Unknown Source)
at com.hxtt.sql.bm.a(Unknown Source)
- locked <0x22ee7298> (a com.hxtt.sql.access.r)
at com.hxtt.sql.ag.a(Unknown Source)
at com.hxtt.sql.ag.a(Unknown Source)
at com.hxtt.sql.ag.executeQuery(Unknown Source)
at AccessTest.main(AccessTest.java:68)

It was taking up to 10 minutes in some cases. After undoing setting that property everything started to work properly but we got the same problem that we have before setting that property: the first read-transaction that tried to see the data just committed for a C++ layer was ok but then, a second java transaction was not seeing that data. Testing with delayedClose=1 and both problems were fixed, namely, 1) performance is right and 2) each java transaction is able to see data just committed from C++.

The questions are: what is the influence of that property? How can we be sure we will be able to read C++ committed data with delayedClose=1? What does that 1 second exactly mean? How does delayedClosed=1 helped in the use case depicted above?

Thanks
Re:Re:Re:Re:Re:Re:Re:Re:Strange behaviour after committing a transaction
HXTT Support
2008-02-21 22:59:31.0
>It was taking up to 10 minutes in some cases.
Supported. We will release a latest package after about 12 hours.

Search Key   Search by Last 50 Questions




Google
 

Address: 9 Station Rd., Xiangtan City, Hunan Province, P.R. China
Postcode: 411100
Phone: (86)731-58225727
Fax: (86)731-58225727
Email: webmaster@hxtt.com
Copyright © 1999-2011 Hongxin Technology & Trade Ltd. | All Rights Reserved. | Privacy | Legal | Sitemap