Main   Products   Offshore Outsourcing   Customers   Partners   ContactUs  
JDBC Databases
  HXTT Access v5.2
  HXTT Cobol v2.1
  HXTT DBF v5.2
 
  Buy Now
  Support
  Download
  Document
  FAQ
  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 DBF
Ongoing problem
JF Laplante
2010-06-06 18:31:59.0
Hi,

This is a continuation to an old thread I started last year. I'm an independant consultant/programmer and one application I'm developing is accessing a flavor of Xbase tables.

Last year I convinced the owner of the company to purchase your JDBC DBF driver after some initial testing showed good results. However; after more testing I found several occasion where your driver wouldn't work properly and I opened a case for that matter. Here's the URL to the original case:

http://www.hxtt.com/support_view_issue.jsp?id=1250781908

You must understand that I spend numerous hours troubleshooting that issue and I cannot bill that tie to my client because it was supposed to work alot more easily than that as it is the case with most database driver I use. I also can't bill my client for the HXTT driver I purchased on their behalf because it simply doesn't work for their application. I am now several hundred dollars 'in the red' because of this driver...

I had to put aside development on this project because my time was needed elsewhere. My support period is ending soon and I would like this issue resolved to my satisfaction.

The last post in the original thread is asking for me to use your HXTT driver to REINDEX the tables. This action causes the other application using those tables to react unfavorably and data is not displayed as it should.

You can read the original thread but tell me how and I will will include a sample table and index and a simple query to run against it.

The simple query:

SELECT * FROM STK WHERE PRO = 'LZZZ '

Doesn not return any results but the Microsoft ODBC VFP driver and the STELS JDBC do return the correct answer.

Those variations does not return any results either (but it does work with the other drivers)

SELECT * FROM STK WHERE PRO = TRIM('LZZZ ')

OR

SELECT * FROM STK WHERE PRO = 'LZZZ'

The only way to retrieve the correct record is with this syntax:

SELECT * FROM STK WHERE TRIM(PRO) = TRIM('LZZZ ')

This forces me to change all my working code to accommodate your syntax and it doesn't resolve the indexing problem that I have as well. The tables are generated by an application written with Alaska Software Xbase ++ developmental environment.


Thanks for your help.

JF.





Re:Ongoing problem
HXTT Support
2010-06-06 19:37:06.0
>The tables are generated by an application written with Alaska Software Xbase
>++ developmental environment.
Alaska supports both of Foxpro and Clipper lock for table, and provides standard and extended Locking scheme for index file. You can try lockType=Clipper or lockType=Foxpro to see whether your issue willl disappear.

If possible, can we get your application and some sample data for test purpose? After we recur and solve your issue, we will delete all of your test case.
Re:Re:Ongoing problem
JF Laplante
2010-06-06 19:57:00.0
If you follow the thread from last year; I already sent you a sample table. If you don't find it; remember me again how I can send send some files to you. I'm presently using locktype=VFP but I don't see how that could prevent the indexes from being corrupted.
Re:Re:Re:Ongoing problem
HXTT Support
2010-06-06 20:16:25.0
stk.zip contains an invalid cdx file, but we need to know which corrupted it.

>I'm presently using locktype=VFP but I don't see how that could prevent the
>indexes from being corrupted.
Only when HXTT DBF and your Alaska application use the same lock type, they can cooperate to do concurrent data modification. That's why we need your Alaska application to recur and detect that your lock type.
Re:Re:Re:Re:Ongoing problem
JF Laplante
2010-06-06 20:22:34.0
The file I sent you last year contained a freshly reindexed file (by the application, not your driver). Since then, my client upgraded his application to a windows based (Alaska made) software from the same company around the same tables but I still have similar problems.

I would like to send you and updated version of this same file. I just reindexed it (with the windows application, not your driver) and zipped it. I'm ready to send it but I need to know how.

Thanks.

JF.
Re:Re:Re:Re:Ongoing problem
JF Laplante
2010-06-06 20:27:53.0
I just read last year's post and I just uploaded a new current copy of the stk.zip archive with a freshly reindexed file from the Alaska Software based application.

Sorry for the confusion.

JF.
Re:Re:Re:Re:Re:Re:Ongoing problem
HXTT Support
2010-06-06 20:35:03.0
Download. But we need that application (any one of old or new version).
Re:Re:Re:Re:Re:Re:Re:Ongoing problem
HXTT Support
2010-06-06 20:45:11.0
Can you make sure that latest index file is not corrupted? It seems that HXTT DBF failed to utilize that index file.
Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
HXTT Support
2010-06-06 21:15:32.0
v4.2.153 fixed a bug on CDX index varchar expression since v4.2.117. It will be release in 2 hours.
Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
HXTT Support
2010-06-07 02:01:28.0
Please download the latest package. If possible, we still wish to get an application to know lockType=? (Foxpro or Clipper).
Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
JF Laplante
2010-06-07 04:50:15.0
The application in itself is a free of charge accounting package. The only problem for you guys is that it is made in French instead of English.

It can be downloaded freely here:

http://webmino.americmedia.com/cgi-bin/webmino.exe?WAA_PACKAGE=ADESD&WAA_FORM=ADMFREE&cSOFT=AD7

It does contain a demo company as well as a re-index feature under its maintenance menu. The table I sent you yesterday was zipped just after executing the re-index feature of this accounting package.

Thanks in advance.

JF.
Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
HXTT Support
2010-06-07 07:14:20.0
Checked. Please use lockType=VFP int your jdbc url. Because we hadn't gotten more reply in the older thread, so that we thought your issue had been solved through REINDEX once. If you meet more issue, please let us know ASAP.
Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
JF Laplante
2010-06-07 07:40:02.0
My locktype is already VFP as stated earlier.

Here's my URL:

jdbc:dbf:///c:/net/dmanica/admino/c001/?lockType=VFP

I take responsibility for last year thread. I decided to quit my efforts because my time was needed somewhere else.

When I issue a re-index with the HXTT driver, they become corrupted to the Alaska Software application. When I re-index with the application; I'm not sure that the HXTT driver can use it and when it writes to the table it seems to corrupt the index sometime.

This is one problem that I have. The other problem is related to SQL an results. I provided sample querries earlier in this thread.

Thanks in advance.

JF.
Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
HXTT Support
2010-06-07 17:39:10.0
>The other problem is related to SQL an results. I provided sample querries
>earlier in this thread.
It has passed in the latest package.

>When I re-index with the application; I'm not sure that the HXTT driver can use >it and when it writes to the table it seems to corrupt the index sometime.
Maybe solved.

>When I issue a re-index with the HXTT driver, they become corrupted to
>the Alaska Software application.
Please retry. That's the key to make sure whether your issue has been solved. If failed, please let us know what's the correct(or wrong) message in ADMINO, since we doesn't know French, and detect only that lock method of ADMINO.
Re:Ongoing problem
JF Laplante
2010-06-08 07:13:16.0
I was not able to test the index problem yet but the query problem seems to be a little better. I will point you in the direction of this Microsoft article regarding spaces in WHERE clauses:

http://support.microsoft.com/kb/316626

Technicaly; this query:

SELECT * FROM STK WHERE PRO = 'LZZZ'

which now works (it wasn't working before the latest release of your driver)

Should return exactly the same result as this query:

SELECT * FROM STK WHERE PRO = 'LZZZ '

because of the ANSI PADDING rule of SQL92. I didn't seen any option to turn that feature ON or OFF but it should be ON by default. This is true regardless of the actual content of the 'LZZZ' record ie.; If it has trailing spaces or not.


I will be able to test the indexes very soon and I will get back to you. I'm more than willing to renew my service agreement as we seem to be aiming toward a solution.

Thanks in advance.

JF.

Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
JF Laplante
2010-06-08 07:23:15.0
Regarding Admino; I'm impressed and pleasantly surprised to see the time you are willing to put to resolve my issues.

If you managed to install and open it with the sample data; You can access the re-index feature at will by using the following method:

- Choose the first menu on the left: 'Syst��me'

- Choose Option '5 - Maintenance'

- Chose Option 'A - Reconstruction des index'

- Push the green 'GO' button
Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
HXTT Support
2010-06-08 08:08:30.0
>because of the ANSI PADDING rule of SQL92. I didn't seen any option to turn that
>feature ON or OFF but it should be ON by default. This is true regardless of the
>actual content of the 'LZZZ' record ie.; If it has trailing spaces or not.
For HXTT Access, we provide
ODBCTrimBehavior Indicates whether works like MS Access ODBC driver to ignore tail space characters in condition expression. You can use null, true, false Default: true
If you need that feature, we can add it into HXTT DBF too.

>If you managed to install and open it with the sample data; You can access
>the re-index feature at will by using the following method:
Thanks. Now we wait for the report of
>When I issue a re-index with the HXTT driver, they become corrupted to
>the Alaska Software application.

>I'm more than willing to renew my service agreement as we seem to be aiming
>toward a solution.
We have renewed free your support service to 2011. HXTT wish our customer can get satisfied support in time.
Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
JF Laplante
2010-06-08 16:16:35.0
That feature (PADDING) would be really great and would render your driver more SQL92 compliant. I also like the case insensitive feature of your access driver.

Another great feature that some other driver have is an option to return empty/null numeric fields as zero.

Thanks for the free support renewal. I'm happy that you gave it to me but I would have paid for it gladly! After all, the long delay is partly my fault.

I have no feedback yet for the indexes, I will get some tomorrow I hope.

Thanks.

JF.
Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
HXTT Support
2010-06-09 00:17:47.0
You can use
properties.setProperty("caseInsensitive", "true");
properties.setProperty("ODBCTrimBehavior", "true");
properties.setProperty("emptyDecimalAsZero", "true");
or
jdbc:dbf:/....yourpath?lockType=VFP;caseInsensitive=true;ODBCTrimBehavior=true;emptyDecimalAsZero=true;

The latest package will be availabe in 2 hours.
Re:Ongoing problem
JF Laplante
2010-06-09 21:52:33.0
Hi,

First I must thank you for the extraordinary service I have received in the last few days. You went above and beyond the call of duty! Many American and Canadian Companies could learn a few things from you!

- The index problem seems to be gone but I will test it furthermore in the next few days.

- The query problem is also gone thanks to the 3 new options you very gently provided me with. It's amazing to me to see how fast you deployed those changes!

I'll keep you informed and continue to follow very closely the products of your company.

For now; all my problems seems settled.

Thanks again.

JF.
Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
HXTT Support
2010-06-09 23:14:09.0
Thanks for your valuable suggestion and response. Any new issue report or suggestion? Please let us know ASAP:)
Re:Ongoing problem
JF Laplante
2010-06-10 14:40:21.0
Further testing today reveled one small problem:

This problem was described last year but I hoped it was gone with the addition of the 'ODBCTrimBehavior=true' option. All the following tests are done with that function set to TRUE.

The only situation I came across this error was with search criteria that include spaces. Using the test database I already sent you;

The following query will retrieve 0 rows but it should retrieve 1 row:

SELECT * FROM STK WHERE PRO = 'L180 PC'

But the following query will return 1 row as it should because I added a TRIM:

SELECT * FROM STK WHERE trim(PRO) = 'L180 PC'

However, a query like the next one with no space in the search criteria will return 1 row even without the TRIM function.

SELECT * FROM STK WHERE PRO = 'L180'


Regarding the ODBCTrimBehavior option; the SQL 92 definitions says that when comparing strings of unequal length, they should be made equal by adding trailing spaces to either the condition expression OR the column being compared. It is described more as a padding than a trimming.

It is well described in the following Microsoft article:

http://support.microsoft.com/kb/316626

In that sense; the following comparison should ALL be equal:

'L180' = 'L180'
'L180 ' = 'L180'
'L180' = 'L180 '
'L180 ' = 'L180 '

If you want to TRIM instead of PAD; both sides of the comparison should be trimmed.

Thanks again for your help.

JF
Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
HXTT Support
2010-06-10 21:39:50.0
According to our test, we found that Alaska Software application is not compatible with VFP's CDX format, if your STK.CDX was rebuild by ADMINO, HXTT DBF will failed to utilize index, if STK.CDX war rebuild by VFP, HXTT DBF can return correct result.
SELECT recno(),* FROM STK WHERE PRO = 'L180 PC'
wrong with STK.CDX
correct without STK.CDX

SELECT recno(),PRO FROM STK WHERE rtrim(PRO) = 'L180 PC'
389 L180 PC correct

SELECT recno(),* FROM STK WHERE trim(PRO) = 'L180 PC'
389 L180 PC correct

SELECT recno(),* FROM STK WHERE PRO = 'L180'
195 L180 correct

select 'L180' = 'L180','L180 ' = 'L180','L180' = 'L180 ','L180 ' = 'L180 '
true true true true correct


Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
HXTT Support
2010-06-10 23:33:44.0
According to our test, ADMINO(Alaska Software application) is not fully compatible with VFP's DBF header(index flag) and CDX format(space index), so that we decided to add a lockType=Alaska connection property.
With lockType=Alaska, HXTT DBF can utilize/maintain your nonstandard index format. The latest package will be availabe in 2 hours.
Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
JF Laplante
2010-06-11 06:32:50.0
Preliminary tests looks very good as the problem is gone! I will put it in production this afternoon and report back to you.

I'm curious by nature and I'm also interested in knowing about this CDX format. Have you ever seen it before? If the problem is in CDX why are we addressing it by using a 'LockType.?

Thanks again.

JF.
Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
HXTT Support
2010-06-11 08:13:34.0
>I'm curious by nature and I'm also interested in knowing about this CDX format.
You can find some information at http://www.clicketyclick.dk/databases/xbase/format/cdx.html#CDX_STRUCT

>Have you ever seen it before?
One system analyst of HXTT has known well it in 1999.

>If the problem is in CDX why are we addressing it by using a 'LockType.?
Because we need a way to tell HXTT DBF how to process it since it is not a standard CDX file with minor key difference. We won't to add more connection property only for that difference.
Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
HXTT Support
2010-06-11 08:17:17.0
I guess that your application won't complain more for corrupted index, since HXTT DBF writes it according its nonstandard index key rule.
Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
HXTT Support
2010-06-11 08:23:13.0
>Doesn not return any results
Because HXTT DBF detects and load that index file automatically although it failed to find index standard CDX structure index flag. When it utilized index, it failed to fetch data since it has minor key difference on space processing.

>but the Microsoft ODBC VFP driver
Because ODBC VFP can't see the standard CDX structure index flag, so that it doesn't load index automatically.

> and the STELS JDBC do return the correct answer.
Because it doesn't use CDX index file at all.

I wish your old issue has ben resolved and you won't meet more new issue:)
Re:Ongoing problem
JF Laplante
2010-06-15 16:39:50.0
Your help has been very valuable to me so far. The problems with table STK seems to be solved but I'm having problems with other tables that are similar to the STK problem I was having.

With test table and index freshly rebuilt by the ADMINO application:

http://www.jflaplante.org/kit.zip


The following query returns no result:

SELECT * FROM KIT WHERE PRO = 'V5959' AND ITM <> '5959'

But this query returns 1 row which is the correct answer:

SELECT * FROM KIT WHERE TRIM(PRO) = 'V5959' AND ITM <> '5959'

When I do:

REINDEX ALL ON KIT

Everything seems to work again with your driver rebuilding the index but after the application rebuilt the index; it stops working. We already know that their index structure is strange. Can you tell something special from the other index I sent you?

Thanks in advance.

JF.

Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
HXTT Support
2010-06-15 17:46:56.0
>Everything seems to work again with your driver rebuilding the index but after >the application rebuilt the index; it stops working. We already know that
>their index structure is strange.
Don't worry. Supported. The latest package will be available in 2 hours.

>Can you tell something special from the other index I sent you?
Found another incompatible rule on index page node for string index.
Re:Ongoing problem
JF Laplante
2010-06-15 18:47:10.0
Thanks again, I will test it when it's available.

I was wondering if there's some kind of 'order' in these 'incompatible rules' or if you're working to create multiple rules to inconsistent exceptions?

Do you think that there's many more of these exceptions?

I really appreciate what you're doing and the last thing I want to do is have you working to support something that is 'unsupportable' it has to make some kind of sense to be worth it.

Thanks again.

JF.

Re:Re:Re:Re:Re:Re:Re:Re:Ongoing problem
HXTT Support
2010-06-15 19:44:08.0
>Thanks again, I will test it when it's available.
Now you can test.

>I was wondering if there's some kind of 'order' in these 'incompatible rules'
>or if you're working to create multiple rules to inconsistent exceptions?
Becasue CDX is unknown structure, so that Alaska hasn't don fully crack.

>Do you think that there's many more of these exceptions?
Should no more.

>I really appreciate what you're doing and the last thing I want to do is
>have you working to support something that is 'unsupportable' it has to
>make some kind of sense to be worth it.
If we don't provide unique solution and support, many architects can't continue their project. Glad to provide support for you:)


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