Main   Products   Offshore Outsourcing   Customers   Partners   ContactUs  
JDBC Databases
  HXTT Access v7.1
  HXTT Cobol v5.0
  HXTT DBF v7.1
 
  Buy Now
  Support
  Download
  Document
  FAQ
  HXTT Excel v6.1
  HXTT Paradox v7.1
  HXTT PDF v2.0
  HXTT Text(CSV) v7.1
  HXTT Word v1.1
  HXTT XML v4.0
Offshore Outsourcing
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
   
   
   
Heng Xing Tian Tai Lab of Xi'an City (abbr, HXTT)

HXTT DBF
HXTT Crash
Oscar San Martin
2012-02-10 07:33:54.0
Hi,

Under conditions of stress, index are not updated....We are working with last package ( 3.0 ). When we have some transaction, hxtt work fine,but when there are many transactions, a lot of transactions are lost and we must re-index often....

You know our plataform : SCO UNIX 5.xx, FoxPlus for Unix, IDX index files...

We have serious problems to continue working with the driver, because our customers are directly affected...we appreciate your help with this issue...

Thanks in advance,
Re:HXTT Crash
HXTT Support
2012-02-10 19:00:18.0
>Under conditions of stress, index are not updated
Try drop all idx index file on your tables.
Re:Re:HXTT Crash
Oscar San Martin
2012-02-10 19:03:16.0
but will happen with other applications that are running FOXPLUS simultaneously? in order to find records ?
Re:Re:Re:HXTT Crash
HXTT Support
2012-02-10 19:11:02.0
HXTT DBF should update all IDX files in time, maybe Foxplus hasn't update index files at once? In my memory, FOXPLUS need set index to aindexfile for index utilization.
Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-02-10 19:12:35.0
Which one of HXTT DBF and Foxplus application failed to find the losted records?
Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-02-10 19:19:39.0
Both app can't find lost records....only reindex with FoxPlus tool allows both sides find lost records...
Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-02-10 19:44:24.0
>Both app can't find lost records.
Whether HXTT DBF and Foxplus insert records concurrently?
Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-02-11 05:16:02.0
FoxPlus insert records and HXTT DBF update its later....changing the key, in oder words : FoxPlus insert a record with number of pre-sales, it can be 1 or more records, then the customer pays the transaction in the java application ( HXTT DBF ) to print the fiscal ticket or invoice, after print, HXTT DBF try to replace pre-sales key with new key ( fiscal )....

The problem often occurs when the java application tries to retrieve the pre-sale as not found....so we should reindex the tables to find pre-sales previously inserted in FoxPlus application...

Thank you so much,
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-02-11 16:17:29.0
>The problem often occurs when the java application tries to retrieve the
> pre-sale as not found...
Then it happened after FoxPlus inserted record, and before HXTT update? So that please check whether your FoxPlus application hasn't updated all IDX files(focus on the IDX file for pre-sales key) in time, since HXTT DBF will utilize index file to find the pre-sale record.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-02-11 16:26:33.0
Foxbase did not open the underlying indexes automatically. You will have to open the indexes yourself before giving the SQL commands. Something like
USE aTable index idxfile1,idxfile2,idxfile3 in 0
USE bTable index idxfile1,idxfile2
insert into .....
What's your FoxPlus application?
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-02-12 11:31:26.0
Well, maybe we do not use the driver correctly, this is the scenario :

1. In the store, long ago used front-end and backoffice application under FoxPlus / Unix / DBF / IDX

2. Then, became necessary to change the points of cash by a JAVA application

3. We install HXTT in both sides, server Unix and Front-end (JAVA cash register) in order to print fiscal ticket o invoice.

4. Our urlconfig.propeerties in Unix is :

server_log=true
server_logfile=log_server.txt
server_autorun=true
server2_log=false
server3_log=false
server=jdbc\:dbf\://200.100.203.1\:4444//u/fachy?lockType\=FOXPRO4UNIX
server2=jdbc\:dbf\://200.100.203.1\:4445//u/maas?lockType\=FOXPRO4UNIX
server3=jdbc\:dbf\://200.100.203.1\:4446//u/ctacte?lockType\=FOXPRO4UNIX
server2_autorun=true
server3_autorun=true


5. In Unix we start HXTT DBF like :

$JAVA_HOME/bin/java \
-Djava.awt.headless=true \
-Djava.library.path=$JAVA_HOME/lib \
-cp $CLASSPATH \
-Xms256M -Xmx1024M -Xss256k -XX:MaxPermSize=256m \
com.hxtt.sql.admin.HxttService

6. We add CGP files to DBF path...

7. Our connection URL is like :

urlDBGes = "jdbc:dbf://200.100.203.1:4444//u/fachy";
urlDBTar = "jdbc:dbf://200.100.203.1:4445//u/maas";
urlDBCta = "jdbc:dbf://200.100.203.1:4446//u/ctacte";

8. In Connecton class we set some properties :

....
....
String databaseDriverName = "com.hxtt.sql.dbf.DBFDriver";

Class.forName( databaseDriverName ).newInstance();

Properties p = new Properties();
p.setProperty( "maxIdleTime", "1440" );
p.setProperty( "lockType", "FOXPRO4UNIX" );
p.setProperty( "lockTimeout", "90000" );

conn = DriverManager.getConnection( urlDB, p );

9. Under normal conditions, with few concurrent transactions no problem, all work fine...

10. Under stress conditions with many concurrent transactions index are corrupted, some records are not recorded in full, ie some fields are left blank..

Question :

How HXTT DBF uses the indexes?, if the tables and their indexes are updated by FoxPlus correctly why IDX are corrupted ??? maybe I need to lock manually when my Java App will update DBF ???..

Some time ago you told me that CGP files are needed only for Clipper, but how HXTT DBF know which index files (IDX) must be updated ??

We are workinkg with last package (3.0), January '12

Thanks in advance,
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-02-12 17:34:04.0
>Some time ago you told me that CGP files are needed only for Clipper, but how
> HXTT DBF know which index files (IDX) must be updated ??
HXTT DBF and Clipper can use CGP to maintain IDX files. But Foxplus doesn't utilize CGP file to maintain IDX file, and "USE aTable index idxfile1,idxfile2,idxfile3 in 0 " should be used in FoxPlus application, otherwise FoxPlus won't maintain unopend IDX files.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-02-12 18:42:35.0
I understand, but can you see our configuration ?, is this correct ?, why indexes are corrupted under stress conditions ??, any ideas ?

Thanks,

Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-02-14 04:19:05.0
v5.1.028 changed lock mode for SCO Foxpro on IDX index file. It'll be available after 20 hours.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-02-14 05:32:59.0
Ok, Can this version run on jre 1.4 ???, we can only run 1.4 on SCO...that is why we use the 3.0 package ( DBF_JDBC30.jar )...

Thanks,
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-02-14 06:21:44.0
>Ok, Can this version run on jre 1.4 ???
Yeah. HXTT DBF provides support for JRE 1.1 ~1.7.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-02-16 14:42:04.0
Ok, we just downloaded and installed v5.1.028, but it is necessary to change the lockType property ??? because today we lost 1 record and we should have reindexing in order to find it. additionally had few transactions today...

Now, lockType property = FOXPRO4UNIX

Thanks,

Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-02-16 16:31:57.0
>Now, lockType property = FOXPRO4UNIX
You needn't.

>because today we lost 1 record and we should have reindexing in order to find it.
Please watch. We have testd SCO Foxplus on SCO 6. If you still get corrupted index file, we need to check your Foxplus application
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-02-16 16:39:31.0
So I need to remove : lockType property = FOXPRO4UNIX ??
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-02-16 16:41:32.0
>So I need to remove : lockType property = FOXPRO4UNIX ??
Sorry. You need lockType=FOXPRO4UNIX
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-02-16 16:48:25.0
So if you need to check our FoxPlus application, that part specifically... when we open DBF and set index files ?, when whe save ?, when ??
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-02-16 16:55:25.0
To see when that index hasn't contain insert record information.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-02-16 17:05:43.0
But you need to see source code : all lines where we save "movimien" table ?, all source code ?, what portion of source code ??
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-02-16 17:16:48.0
We needn't source code. If you have source code, please maker sure all table is "using atabe ... shared" mode open.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-02-16 19:19:10.0
Well, table is opened in shared mode ( NON EXCLUSIVE ), and when FoxPlus save, only lock RECORD temporary then RECORD is unlocked...

Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-02-16 19:31:18.0
>only lock RECORD temporary then RECORD is unlocked
When it update IDX file, it locks/unlock IDX file too.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-02-16 19:33:31.0
Yeah, index are unlocked too....
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-02-25 10:31:03.0
So, any idea about this issue ?

Thanks,

Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-02-26 02:48:38.0
What's your curren't issue? According to our test on SCO Unix 6, HXTT DBF should lock your IDX file like SCO Foxpro
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-02-26 09:25:11.0
Well, we still lost some records and we need to re-index under FoxPlus in order to find it...
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-02-26 16:17:35.0
>>>The problem often occurs when the java application tries to retrieve the
>>> pre-sale as not found...
>>Then it happened after FoxPlus inserted record, and before HXTT update? So that please check whether your FoxPlus application hasn't updated all IDX files(focus on the IDX file for pre-sales key) in time, since HXTT DBF will utilize index file to find the pre-sale record.
> Well, we still lost some records and we need to re-index under FoxPlus in order to find it...
We need to recur your issue. Please provide more information or test sample so that we can recur your issue.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-02-27 03:41:32.0
just to clarify, work in SCO with FoxBase not FoxPro....


Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-02-27 04:51:19.0
Checked. Foxpro 2.6 for SCO Unix.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-02-27 06:22:39.0
This are our versions:

Multi-User SCO FoxBASE+ 2.1.2

Unix: SCO_SV 3.2 5.0.7 i80386
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-02-27 08:27:36.0
Where we can get FoxBase+ for test purpose?
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-03-01 08:45:24.0
Well, I've two diskettes images ( 1440 KB) : Sco Foxbase Unix and SLS Foxbase Unix ( Y2K path ), with their respective activation key and password. I can send you in order to install and test. Tell me where I can send you.

Thanks,
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-03-01 08:47:18.0
This images must be installed with SCOADMIN tool under SCO Unix.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-03-01 16:13:38.0
You can zip and upload your database sample into:
ftp site: ftp.hxtt.com
ftp user: anonymous@hxtt.com
ftp password: (empty)
login mode: normal (not anonymous)
ftp port:21
upload directory: incoming
transer mode: binary (not ASCII)
After upload, you can't see that upload file, but it has been upload.

After we test, we will remove it soon.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-03-01 16:59:40.0
I sent you two files :

1. disk838.dat (Sco Foxbase Unix) => disk Scofoxbase
2. disk870.dat (SLS Foxbase Unix)=> disk SLS foxbase ( Y2K path )

to install :

- Rename file disk838.dat to : VOL.000.000
- Install it with scoadmin

- Rename file disk870.dat to : VOL.000.000 ( yes same name )
- Install it with scoadmin

Serial number = snd000001
activation Key = mmxljvch

This install FoxBase on SCO Unix, tell me if you need our database sample ( DBF + IDX ).

Thanks in advance.

Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-03-01 18:54:58.0
Thanks. Download it.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-03-09 04:03:29.0
Can you test FoxBase on SCO ?, are FoxBase IDX's and HXTT 100% compatible ?

Unfortunately our client returned to the previous system pending the outcome of the tests by You, because many records were lost under conditions of stress in his store.

We are very attentive to your news.

Thanks,
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-03-11 05:02:44.0
It seems that SCO 6 will throw some errors and failed to install Foxbase.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-03-11 05:56:59.0
Our customer work with SCO 5.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-03-11 06:02:44.0
Versions are :

Multi-User SCO FoxBASE+ 2.1.2

Unix : SCO_SV 3.2 5.0.7 i80386
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-03-11 06:09:43.0
According to our google result:
You can move your licensed foxbase product from OSR5 to OSR6 simply by
copying the /usr/lib/foxplus directory and relevant /usr/bin scripts;
no need to reinstall and relicense.

If the FoxBASE+ application is running on Openserver 5, then you need
only backup the FoxBASE files as well as your application directory
then restore them to the Openserver 6 hard disk. Subsequently, FoxBASE
will not be visible in custom but it will run. Also backup the FoxBASE
perms file: /etc/perms/fox+

In fact, examine /etc/perms/fox+ and it will give you a list of files
and directories you need to back up.

The only file in the installation that is searilized is
/usr/lib/foxplus/foxplus.pr

The SCO FoxBASE+ installation files are not Openserver 5 compliant
indicating that they don't update the "custom" database.

Instead of custom->software->verify, you run fixperm /etc/perms/fox+
to set (correct) the FoxBASE+ directory permissions.

If you do run the standard installation on FoxBASE+, the installation
will generate an error message
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-03-11 06:23:45.0
From what I understand, you need we backup and send you /etc/perms/fox+ and /usr/lib/foxplus/foxplus.pr ?
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-03-12 03:54:06.0
We tried untar disk838.dat and copy it. It will prompt
This program has not been serialized.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-03-12 06:09:55.0
v5.1.036 provides FOXBASE4UNIX lock type for Foxbase2.1 on SCO Unix. We should have guessed out the lock for IDX of FoxBase although we haven't installed it successfully.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-03-12 06:19:58.0
We'll send you doc with screens for installation procedure. This procedure work fine to us.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-03-12 06:56:45.0
Thanks. You can download the latest package.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-03-12 07:21:51.0
Downloaded and testing...

Thanks,
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-03-12 20:26:22.0
>We'll send you doc with screens for installation procedure. This procedure work fine to us.
Welcome
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-03-13 19:08:39.0
Well, I just send "foxbase_install.rar" file via FTP.

Please refer to README.TXT for instructions.

Thanks in advance,
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-03-14 00:52:46.0
Checked. The older package has used the same lock. Any issue? Just let us know.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-03-14 03:19:48.0
Today we'll try
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-03-14 04:32:44.0
The older package means the v5.1.036
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-03-14 04:50:09.0
Yes, 5.1.036 we'll try today....
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-03-15 12:55:41.0
Well, we tried v5.1.036 and at 16:30 hr driver crashed....and many records were lost, we had to reindex...

Thanks,

Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-03-18 06:51:57.0
Please download the latest package again. If you failed still, we need a simple test sample to recur your issue.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-03-20 05:44:40.0
Well, we tried last package and yesterday we lost 2 trx :

Error ejecutaQuery : Failed to update Record 247211 because of corrupted index file:Please reindex index expression CLAVE: Found some recursive information at:7375872

Please tell us what you need en order to recur our issue...

Remember that there are two systems updateing DBF : FoxBase and Java ( HXTT )

Thanks
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-03-20 06:03:08.0
For instance, a simple Foxbase program repeat insert/update some records, and a Java program do that at the time to recur your issue.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-03-26 13:20:06.0
we are preparing the test programs...I hope to send within 48 hours
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-03 12:33:53.0
Well, I'just send file TestHxtt.rar. This file have two folder : FoxBase and Java

First run FoxBase xx prg, in screen folder are instructions in order to run.......this program insert many records on movimien.dbf....

then, without cancel xx FoxBase program you must run java application with 3 parameters : ip port and cash register number (1)...

After a few seconds index are corrupted and java program continue updating records, but FoxBase program have locked table....(¿?)

Please tell us if you need ADDITIONAL INFORMATION ...

Thanks,
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-05 00:53:55.0
I haven't run your test sample still. In your xx.prg, you have "USE MOVIMIEN exclusive", not in shared mode?
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-05 04:43:31.0
Yes, is in exclusve mode....but test program run ? or crash when is running and you run java test ???
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-05 06:25:12.0
Additionally if foxbase open table in exclusive mode, why Hxtt can continue updating records ??? is this right ?
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-05 07:15:24.0
>Additionally if foxbase open table in exclusive mode,
> why Hxtt can continue updating records ???
Tested. HXTT DBF and Foxplus 4 SCO Unix can see each other when on exclusive mode. So they don't do concurrent update anytime for your test case.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-05 07:37:58.0
Your xx sample throw "String memory variable area overflow" for "PARAMETERS ERRNUM , MESG , PROGRAMA"

BTW, you should check your service side: "jdbc:dbf://" + ip + ":" + port + "//u/fachy
On server side, your jdbc url should have //u/fachy?lockType=FOXBASE4UNIX" jdbc url, becaseu server side service can't be changed by connection property of client side for security consideration.

If your application is running on the same host, you can use directly embedded mode, and discard server/client mode too.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-05 07:54:24.0
>On server side, your jdbc url should have //u/fachy?lockType=FOXBASE4UNIX" jdbc >url, becaseu server side service can't be changed by connection property of >client side for security consideration.
Our server urlconfig.properties have lockType=FOXPRO4UNIX...

>If your application is running on the same host, you can use directly embedded >mode, and discard server/client mode too.
Server is running FoxBase app and HXTT service...cash register clients are running in each Linux Ubuntu PC.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-05 07:57:55.0
Here our urlconfig.properties:

#
#Tue Mar 24 01:17:42 GMT-04:00 2009
server_log=false
server2_log=false
server3_log=false
server=jdbc\:dbf\://200.100.203.253\:4444//u/fachy?lockType\=FOXPRO4UNIX?lockTimeout\=120
server_autorun=true
server2=jdbc\:dbf\://200.100.203.253\:4445//u/maas?lockType\=FOXPRO4UNIX
server2_autorun=true
server3=jdbc\:dbf\://200.100.203.253\:4446//u/ctacte?lockType\=FOXPRO4UNIX
server3_autorun=true
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-05 08:01:56.0
>Our server urlconfig.properties have lockType=FOXPRO4UNIX
Please changed it to lockType\=FOXBASE4UNIX
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-09 11:22:41.0
I just sent you the two files : sharedversion.rar and Screenshot-ZZ.PRG.png

In shared version file we have zz Fox program....we're testing FOXBASE4UNIX property in development environment to reduce the inpact on production environment.

You can see there are also records not found.

Thanks.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-09 17:13:13.0
>I just sent you the two files : sharedversion.rar and Screenshot-ZZ.PRG.png
Have you recurred your issue for exclusive mode?
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-09 17:23:49.0
Yes, and we do not understand why java program can update dbf when FoxBase is indexing tables in exclusive mode....
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-10 00:51:03.0
>Yes, and we do not understand why java program can update dbf when FoxBase
> is indexing tables in exclusive mode....
But HXTT DBF can't open a table when FoxBase is opening it on EXCLUSIVE mode.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-10 01:05:45.0
For instance, you can use
foxplus
set exclusive off
use atable

Then in another terminate window,
with lockType=FOXBASE4UNIX connetion porperty, your java application can't run "select * from atable" sql, and throw an exception to tell you that table is locked by another process.

So it's impossible to update a table, when it's opened by Foxplus in exclulsive mode.

If you can, please check whether your DBF_JDBC30.jar is too old to support that connection property.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-10 01:18:24.0
For your latest test sample, zz.fox will prompt still
String memory variable area overflow
PARAMETERS ERRNUM , MESG , PROGRAMA
Called from - /usr/jnitest/bloquea.fox
Called from - /usr/jnitest/bloquea.fox
Called from - /usr/jnitest/bloquea.fox
Called from - /usr/jnitest/bloquea.fox
Called from - /usr/jnitest/bloquea.fox
Called from - /usr/jnitest/bloquea.fox
Called from - /usr/jnitest/bloquea.fox
Called from - /usr/jnitest/bloquea.fox
Called from - /usr/jnitest/bloquea.fox
Called from - /usr/jnitest/bloquea.fox
Called from - /usr/jnitest/bloquea.fox
Called from - /usr/jnitest/bloquea.fox
Called from - /usr/jnitest/bloquea.fox
Called from - /usr/jnitest/bloquea.fox
Called from - /usr/jnitest/bloquea.fox

Cancel, Ignore, or Suspeed?


java appliction will prompt
Trying UPDATE PRE-SALES NBR:31
exception thrown:
java.sql.SQLException: Record of 15 in movimien has been locked by another process
exception thrown:
java.sql.SQLException: rollback failed: Record of 11 in movimie has been locked by another process
java.sql.SQLException: Record of 11 in movimie has been locked by another process
...
java.sql.SQLException: rollback failed: Record of 14 in movimie has been locked by another process
Error...

So that HXTT DBF can see the lock from your zz.fox, but your Foxplus sample will failed for dead loop call?
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-10 09:48:54.0
In order to prevent memory variable area overflow, I just upload file foxplus.rar, this file must be unrar in SCO Unix in : usr/lib/foxplus.

On the other hand, we can't replicate exception :

>exception thrown:
>java.sql.SQLException: Record of 15 in movimien has been locked by another >process

How can you reproduce this issue, we downloaded last package ( March 31 )

Thanks
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-11 04:22:29.0
After unjar it, if I run "foxplus"
It will show
Memory fault
Illegal instruction
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-11 04:26:53.0
>How can you reproduce this issue,
Because I met "Cancel, Ignore, or Suspeed? ", which Foxplus lock that table, so that HXTT DBF can't continue UPDATE or rollback.

> we downloaded last package ( March 31 )
Please check and make sure that HXTT DBF can't access a table if it's opened by Foxplus exclusively.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-18 11:49:02.0
Well, finally we test HXTT driver on production environment, with FOXBASE4UNIX property and :

1. When we run Java app, FoxPlus app can't access DBF tables because DBF are locked (?)

This is a good notice, but we need lock only record and not lock all table

2. Question : is a good practice that java app connect to HXTT at startup and keep connection alive ??? or is it better to connect and close in each transaction ???, now java app open connection and and keeps it alive.

If open/close in each transaction is better...how can Java app open connection in read only mode ( p.e. for reports, queryes, etc )

If we set FOXPRO4UNIX property, both app ( java and foxplus ) can access DBF concurrently....but this option causes corrupted index....sometimes...

Thanks.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-18 17:25:29.0
>1. When we run Java app, FoxPlus app can't access DBF tables because DBF are
> locked (?)
>This is a good notice, but we need lock only record and not lock all table
No. Only for "set exclusive on"

>2. Question : is a good practice that java app connect to HXTT at startup and
> keep connection alive ??? or is it better to connect and close in each
> transaction ???,
Connect and close when your appliction need and needn't it. Not for the application live time(too long), or each transaction( too frequently). But you can choose free.

>how can Java app open connection in read only mode ( p.e. for reports, queryes, etc )
connection level (doesn't allow all delete/update/insert sql):
java.sql.Connection.setReadOnly(boolean readOnly);
or statement level(open talbe in read only mode, and can't modify data through ResultSet object):
Statement stmt = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY);

>If we set FOXPRO4UNIX property, both app ( java and foxplus ) can access DBF
> concurrently.
Because HXTT DBF and Foxplus can't see each other for FOXPRO4UNIX, but HXTT DBF and SCO Foxpro can see each other with FOXPRO4UNIX. With FOXBASE4UNIX, HXTT DBF and Foxplus can see each other for our test, but now my test Foxplus has corrupted after replaced with your foxplus.rar . If you met issue, we will reinstall it.



Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-18 17:42:00.0
But HXTT can lock only one record ??, if I ask for _lockFlag_ and FoxPlus have locked the record, _lockFlag_ is turned to "true" or only other java app can turn true this flag ???
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-18 18:08:10.0
>But HXTT can lock only one record ??
Yeah. It's automatically.

>if I ask for _lockFlag_ and FoxPlus have locked the record, _lockFlag_ is
> turned to "true"
Yeah. I don't know whether there's a rlock fuction for FoxPlus, but HXTT DBF can lock record automatically or manually.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-18 19:07:45.0
Ok, but we have this issue :

1. Start HXTT Service ( with FOXBASE4UNIX property )
2. Start FoxPlus APP

FoxPlus APP open table in NO exclusive mode ( set exclusive off ) and work fine inserting records into table movimien.dbf... like :

append blank
REPLA record(recno()) field1 WITH data1,field2 WITH data2,field3 WITH....
REPLA record(recno()) field4 WITH data4....
REPLA record(recno()).....
.....
.....

record(recno()) => lock only current record

3. Start Java APP ( FOXBASE4UNIX ) and try to connect with HXTT and immediately FoxPlus APP send error because Java APP apparently lock all table movimien, as if another foxplus program open table movimien as "set exclusive on"...


...in short, only one application can run simultaneously ( Java or Foxplus ), but not both...

We think we are close to the solution....

Thanks in advance.

Thanks,
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-18 19:23:39.0
>record(recno()) => lock only current record
Do you means that Foxplus has a manual record lock function? RLOCK function was provided since Foxpro. I doen't know how to set manually record lock through what function or command in Foxplus.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-18 19:35:43.0
yeah,record(recno()) => lock only current record in append mode, but what about :

>3. Start Java APP ( FOXBASE4UNIX ) and try to connect with HXTT and immediately >FoxPlus APP send error because Java APP apparently lock all table movimien, as >if another foxplus program open table movimien as "set exclusive on"...
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-18 20:19:22.0
>Start Java APP ( FOXBASE4UNIX ) and try to connect with HXTT and immediately
>FoxPlus APP send error
What's the error message?
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-19 04:20:06.0
FoxPlus detect that table movimien is iocked in exclusive mode....
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-19 06:53:59.0
According to our test:

import java.io.InputStream;
import java.io.PrintStream;
import java.sql.*;
import java.util.Hashtable;
import java.util.Properties;

public class testLock5
{

public testLock5()
{
}

public static void main(String argv[])
{
try
{
String url = "jdbc:dbf:////usr/jnitest";
String sql4rowlocked = "select recno(),_lockFlag_,* from [table] where recno()=2;";
String lockTypes[] = {
"Foxbase4UNIX"
};
Class.forName("com.hxtt.sql.dbf.DBFDriver");
Properties properties = new Properties();

System.out.println("Try use table exclusive in Foxbase, and you will get true");
for(int i = 0; i < lockTypes.length; i++)
{
properties.put("lockType", lockTypes[i]);
Connection con = DriverManager.getConnection(url, properties);
Statement stmt = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_UPDATABLE);
try
{
ResultSet rs = stmt.executeQuery(sql4rowlocked);
if(rs.next())
System.out.println(rs.getObject(1));

rs.updateBoolean("_LockFlag_",true);//Lock Row
rs.updateRow();
System.out.println("Y or C to continue");
int flag;
do
flag = System.in.read();
while(flag != 'Y' && flag != 'y' && flag != 'C' && flag != 'c');

rs.close();
rs = null;
}
catch(SQLException sqle)
{
System.out.println(lockTypes[i] + " failed for tryLock");
do
System.out.println(sqle.getMessage());
while((sqle = sqle.getNextException()) != null);
}
stmt.close();
con.close();
}



}
catch(SQLException sqle)
{
do
{
System.out.println(sqle.getMessage());
System.out.println("Error Code:" + sqle.getErrorCode());
System.out.println("SQL State:" + sqle.getSQLState());
sqle.printStackTrace();
} while((sqle = sqle.getNextException()) != null);
}
catch(Exception e)
{
System.out.println(e.getMessage());
e.printStackTrace();
}
}
}



After run that testLock5,
in foxplus,
use table
go 2
REPLA record(recno()) name WITH '333'
will prompt:
Record is use by other.
brow
will prompt:
File is in use by another
display
will show that record 2 content.

Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-19 06:55:23.0
So HXTT DBF and SCO Foxplus can see each other now, but brow command can't run now.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-19 07:04:44.0
Two instance of Foxplus cannot run "brow" command at the same time, so that "brow" command should require a table lock.

>FoxPlus detect that table movimien is iocked in exclusive mode....
Please let us know, since HXTT DBF is using table in shared mode. BTW, we tested only table without IDX index. Maybe you met issue because index file can't be modified in share mode.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-21 12:20:26.0
Well, after several tests I can determine that the only way to use both applications is is opening and closing the connection for each query from java, because if I leave the connection open, FOXPLUS detects that the table is open in exclusive mode, which is not real, and can't insert new records....( loop waiting for unlock table ).

In order to open and clossing for each query I copy ResultSet to CachedRowSet like : cachedRs.populate( rs ), then I close Statement and Connection....

This leaves java app slow, but is the only way to run.

We believe that FOXBASE4UNIX work fine in order to tell us when DBF is locked, because FOXPRO4UNIX can't tell us it, but FOXBASE4UNIX fail when connection is alive, because lock table....


Thanks
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-21 17:08:26.0
>but FOXBASE4UNIX fail when connection is alive, because lock table....
>because if I leave the connection open, FOXPLUS detects that the table is open in
> exclusive mode, which is not real, and can't insert new records....( loop
> waiting for unlock table ).
If possible, please write a simple test demo so that we can recur it. In our test, Foxplus can open table when HXTT DBF hold lock on the same table.

Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-23 15:41:42.0
Well, after many tests, we can reproduce this issue :

1. Run Java app and open connection like :

....
....
conn = DriverManager.getConnection( urlDB, p );
conn.setReadOnly( true );
....
....

2. Read some parameters from DBF's like :

....
....
Statement s = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY );
rs = s.executeQuery( queryStr );
....
....

3. One parameter is read from "setup1.dbf" table...

4. If Java app close connection or not....when I run foxplus app, foxplus send :
Exclusive lock failed for line "use setup1 exclusive"...but I was close connection to DBF's in Java app...

If I insert a loop in foxplus in order to detect unlock from HXTT, after 20 or 30 seconds foxplus can continue...

Question : Why HXTT that does not release immediately the tables when I close conn?,

think in an environment with 10 clients runnng java app trying to access simultaneously DBF tables...

Thanks


Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-23 15:59:40.0
In the other hand, Java app open connection in read only mode...
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-23 18:38:07.0
Failed to recur your issue. On read-only mode, Foxplus can open it when HXTT connection is opening or closed.


import java.io.InputStream;
import java.io.PrintStream;
import java.sql.*;
import java.util.Hashtable;
import java.util.Properties;

public class testLock6
{

public testLock6()
{
}

public static void main(String argv[])
{
try
{
String url = "jdbc:dbf:////usr/jnitest";
String sql4rowlocked = "select recno(),_lockFlag_,* from [table] where recno()=2;";
String lockTypes[] = {
"Foxbase4UNIX"
};
Class.forName("com.hxtt.sql.dbf.DBFDriver");
Properties properties = new Properties();

System.out.println("Try use table exclusive in Foxbase, and you will get true");
for(int i = 0; i < lockTypes.length; i++)
{
properties.put("lockType", lockTypes[i]);
Connection con = DriverManager.getConnection(url, properties);
con.setReadOnly( true );
Statement stmt = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY );
try
{
ResultSet rs = stmt.executeQuery(sql4rowlocked);
if(rs.next())
System.out.println(rs.getObject(1));

System.out.println("Y or C to continue");
int flag;
do
flag = System.in.read();
while(flag != 'Y' && flag != 'y' && flag != 'C' && flag != 'c');

rs.close();
rs = null;
}
catch(SQLException sqle)
{
System.out.println(lockTypes[i] + " failed for tryLock");
do
System.out.println(sqle.getMessage());
while((sqle = sqle.getNextException()) != null);
}
stmt.close();
con.close();
}


System.out.println("Y or C to exit");
int flag;
do
flag = System.in.read();
while(flag != 'Y' && flag != 'y' && flag != 'C' && flag != 'c');
}
catch(SQLException sqle)
{
do
{
System.out.println(sqle.getMessage());
System.out.println("Error Code:" + sqle.getErrorCode());
System.out.println("SQL State:" + sqle.getSQLState());
sqle.printStackTrace();
} while((sqle = sqle.getNextException()) != null);
}
catch(Exception e)
{
System.out.println(e.getMessage());
e.printStackTrace();
}
}
}
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-23 19:22:07.0
Can you send us your foxplus code to test testLock6 class ?

Thanks
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-23 19:32:06.0
foxplus
use table excluse
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-24 13:50:27.0
We can solve lock problem, but, now, running test we receive this exception :

1st time :

java.sql.SQLException: Failed to update record 206 because of corrupted index file:please reindex index expression CLAVE: Stopped at:12288 for node depth bigger than 512

2nd time:

java.sql.SQLException: Failed to update record 1111 because of corrupted index file:please reindex index expression VAL(LTRIM(RTRIM(NDOC))):Stopped at:13312 for node depth bigger than 512

Thanks

Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-24 17:01:42.0
>We can solve lock problem
If we can recur your issue, maybe we can find better solution.

>Stopped at:12288 for node depth bigger than 512
Whether your index file is too big or that file is corrupted? What's your reccount() value? Please check whether your Foxplus can use the same CLAVE index to display in order, and if it can, it means that your index file is too big, and node depth is bigger than 512.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-26 17:42:30.0
Well, finally now we can work with both app...lock is working fine...._lockFlag_ and recno() was the solution....

Our last issue ( we hope the last ) is when corrupted index file... we're testing on small table ( 1000 records max ), which could be the cause?

If you can test with our tables ( send you test environment in order to replicate this issue ), is this useful???

Thanks,
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-26 20:43:29.0
You can send. But first:

>we're testing on small table ( 1000 records max ), which could be the cause?
>>Whether your index file is too big or that file is corrupted? What's your reccount() value? Please check whether your Foxplus can use the same CLAVE index to display in order, and if it can, it means that your index file is too big,
> and node depth is bigger than 512.
>Stopped at:13312 for node depth bigger than 512
If Foxplus can use the same CLAVE index to display in order, then that CLAVE index is correct but with a index depth more than 512. HXTT DBF
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-26 21:36:20.0
You can send. But first:

>we're testing on small table ( 1000 records max ), which could be the cause?
>>Whether your index file is too big or that file is corrupted? What's your reccount() value? Please check whether your Foxplus can use the same CLAVE index to display in order, and if it can, it means that your index file is too big,
> and node depth is bigger than 512.
>Stopped at:13312 for node depth bigger than 512
If Foxplus can use the same CLAVE index to display in order, then that CLAVE index is correct but with a index depth more than 512. HXTT DBF throws exception becasue it doesn't think such an index depth is suitable, and we can adjust it to 1024 depth.
If Foxplus failed too, then that CLAVE index is invalid. we NEED to recur your issue.




Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-27 05:17:12.0
Both app fail when index corrupted, in other words, we need reindex under Foxṕlus tool because Foxplus app can't find records too...

First we will test the latest changes in production ( lock issue )...

We hope to have news on next saturday....if index is corrupted, we'll send you our test environment.

Thanks in advance,
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-27 15:07:03.0
Lock qustion,

Now we can work with both app over DBF's ( java and foxplus ), lock work fine when java try select one table like "select recno(), _lockFlag_, * from [table] where...."

However, how can I work with this type of queries :

- SELECT SUM( some_field ) as result FROM [table] WHERE field2 =......
- SELECT COUNT( some_field ) as result2 FROM [table] WHERE field3 =......

Especially:

- SELECT DISTINCT( some_field ) as result2 FROM [table] WHERE field4 =......

- SELECT * FROM [table1] t, [table2] t2 WHERE t1.field1 = t2.field2, .....

Because foxplus modules can't access tables in exclusive mode when java execute this queries...for example to re-index with foxplus tool.


Thanks,


Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-27 17:20:31.0
>lock work fine when java try select one table like "select recno(), _lockFlag_,
> * from [table] where...."
I don't think _lockFlag_ is necessary since HXTT DBF will lock/unlock automatically your table for lockType=? mode. _lockFlag_ is useful for manual lock.

>Because foxplus modules can't access tables in exclusive mode when java execute
> this queries.
Because INDEX file need to lock/unlock in exclusive mode when HXTT DBF utilizes it for WHERE clause. If your INDEX file is bigger, you need to set a bigger lockTimeout value for HXTT DBF, and For Foxpro:
SET REPROCESS Command
Specifies how many times and for how long Visual FoxPro attempts to lock a file or record after an unsuccessful locking attempt.
SET REPROCESS TO nAttempts [SECONDS] [SYSTEM] | TO AUTOMATIC [SYSTEM]
SYS(3051) - Set Lock Retry Interval
Specifies the time in milliseconds that Visual FoxPro waits before attempting to lock a record, table, memo, or index file after an unsuccessful locking attempt.
SYS(3051, [nWaitMilliseconds])
SYS(3052) - Override SET REPROCESS Locking
Specifies whether Visual FoxPro uses the SET REPROCESS setting when attempting to lock an index or memo file.
SYS(3052, nFileType, [lHonorReprocess])

I guess SET REPROCESS TO command should be in Foxplus too.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-27 17:33:03.0
lockTimeout must be set in server side and client side ??? what are that range of values ?

Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-27 17:45:49.0
>lockTimeout must be set in server side and client side ??
Server side, and client side can't change server side value. But I guess that HXTT DBF won't throw timeout, and your Foxpro will throw at once.

>what are that range of values ?
lockTimeout To specify DBF driver's timeout in milliseconds to wait until other processes or Xbase applications released record lock or table lock. 0 means a default value, and <0 means no wait.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-28 12:59:32.0
We are really complicated, first, very time ago, we set FOXPRO4UNIX property, then we detect some records not found by HXTT, then we changed to Foxbase4UNIX...here we can't work with both app over DBF's simultaneously, then we detect that "SELECT * FROM WHERE..." lock DBF's, we put recno() and _lockFlag_ into each SELECT query....and now we can wotk fine with both app....

Then, when java app open some tables for read only and if foxplus try to reindex, foxplus crash because foxplus can't open table in exclusive mode...

..then we set lockTimeout property to 120, now foxplus can reindex fine, lock work fine, but now Java app can't find all records and find only some....

Can someone tell us if HXTT have other experience with foxplus over Unix ?

Thanks in advance...
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-28 17:24:27.0
You should be the only Foxplus on SCO unix.

>Then, when java app open some tables for read only and if foxplus try to reindex,
> foxplus crash because foxplus can't open table in exclusive mode...
Visual FoxPro doesn't place a lock on a file when executing commands that require read-only access to a table. These commands include the following:
SET LOCK ON | OFF
Parameters

ON

Specifies that the commands listed below automatically lock the table when they execute. This provides read-only access to other users on the network and ensures that you are using the most current data.

OFF

(Default) Enables shared access of tables with commands listed below. Use SET LOCK OFF if you don't need the most current information from a table.


Whether Foxplus has a simliar command?

>..then we set lockTimeout property to 120, now foxplus can reindex fine, lock work fine, but now Java app can't find all records and find only some....
It's strange, what's your jdbc url setting? With lockTimeout, HXTT DBF should use lockType still so that you can't reidex file still.


Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-29 10:29:24.0
Yes, it is very very strange, some records are found and others are not found...we tried changing original "WHERE" sentence in SQL query from :

SELECT recno(), _lockFlag_, * FROM [table]
WHERE field = '" + someNbr + "' AND " +
field2 = '' AND
(field3 = 'S' OR field4 = 'T' ) AND
field5 = '" + someDate + "' AND
(field6 = '7' OR field6 = '8' OR fild6 = '9');

...To...

SELECT recno(), _lockFlag_, * FROM [table]
WHERE Alltrim(field) = '" + someNbr + "' AND " +
Alltrim(field2) = '' AND
(Alltrim(field3) = 'S' OR Alltrim(field4) = 'T' ) AND
field5 = '" + someDate + "' AND
(Alltrim(field6) = '7' OR Alltrim(field6) = '8' OR Alltrim(field6) = '9';

...and behavior sometimes varies, sometimes the same.

Here our urlconfig.properties in server side :

server_log=false
server2_log=false
server3_log=false
server=jdbc\:dbf\://200.100.203.253\:4444//u/fachy?lockType\=FOXBASE4UNIX?lockTimeout\=120
server_autorun=true
server2=jdbc\:dbf\://200.100.203.253\:4445//u/maas?lockType\=FOXBASE4UNIX
server2_autorun=true
server3=jdbc\:dbf\://200.100.203.253\:4446//u/ctacte?lockType\=FOXBASE4UNIX
server3_autorun=true

Here our jdbc url setting in client side :

urlDBGes = "jdbc:dbf://200.100.203.253:4444//u/fachy";
urlDBTar = "jdbc:dbf://200.100.203.253:4445//u/maas";
urlDBCta = "jdbc:dbf://200.100.203.253:4446//u/ctacte";


Then, in class instance for each connection :

....
....
Properties p = new Properties();
p.setProperty( "maxIdleTime", "1440" );
p.put("lockType", "Foxbase4UNIX" );
p.put("lockTimeout", 120 );
....
....

Thanks,
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-29 17:11:13.0
>server=jdbc\:dbf\://200.100.203.253\:4444//u/fachy?lockType\=FOXBASE4UNIX?lockTimeout\=120

Your jdbc url should be wrong when you modification to add more than one connection property.
>FOXBASE4UNIX?lockTimeout\=120
? should be ; or &

Please let us know whether Foxplus has a similar command to work like Foxpro to allow unlock mode on readonly mode. Then we can consider to simulate it.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-29 19:42:04.0
Well, some equivalences between foxbase an foxpro :

foxpro SET LOCK ON / OFF >> Foxbase es SET EXCLUSIVE ON /OFF

When foxbase append new record with set exclusive off, recno() locks only record appened, like :

append blank
REPLA record(recno()) field1 WITH value1, field2 WITH value2, field3 WITH value3
REPLA record(recno()) FORMADPAGO WITH FPAGO
REPLA record(recno()) FACTOROFER WITH FFACT1
....
....


As we are the only ones with this configuration, please do not hesitate to request the information necessary about foxbase and foxpro equivalence...

Thanks
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-29 20:46:20.0
>When foxbase append new record with set exclusive off, recno() locks only
> record appened, like :
But on SET EXCLUSIVE ON, no other Foxplus window can open the same table. You can try it.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-04-30 17:28:09.0
Yes, what I said, when foxplus app append new blank record, foxplus set SET EXCLUSIVE OFF, since recno() lock only appened record....

generally, foxplus app open tables with SET EXCUSIVE OFF, rarely we used SET EXCLUSIVE ON basically to increment a counter because all tables are in shared mode...


Thanks,
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-04-30 17:47:04.0
Then whether HXTT DBF and Foxplus can work normaly together on shared mode?

>Then, when java app open some tables for read only and if foxplus try to reindex,
> foxplus crash because foxplus can't open table in exclusive mode...
But you wish Foxplus can do exclusvie reindex when HXTT DBF is doing read-only operation without lock?
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-05-05 18:07:24.0
New issue solved (¿?)...

Java app try "select recno(), _lockFlag_, * from [table] where key = ...", and work fine...

Foxplus try :

use [table], index1, index2, index3, index4, index5, index6 exclusive
...then update or insert new record
...then use ( in order to close table )

and foxplus send : "File write error"

So, java app only "select" some record from same table...

we solved the problem deleting "item.cgp" file and restart hxtt service...

Questions:

1. Are cgp's files strictly necessary ?
2. If we need to update some record in a table without cgp file....are slower ??
3. When cgp's files are strictly necessary ?

Thanks,
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-05-06 00:41:31.0
>we solved the problem deleting "item.cgp" file and restart hxtt service...
loadIndices=false should be useful. Without cpg file, HXTT DBF won't maintain those index files.

It seems that you need to use the table when Foxplus us it exclusive?

>>But you wish Foxplus can do exclusvie reindex when HXTT DBF is doing read-only operation without lock?

So I think you shoud descript your requirements so that we can find a solution, but won't let your index file out of control.

Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-05-06 10:40:53.0
But if I use : loadIndices=false, when java try find one record, this should be slower ???.

By example, our item.dbf have 25.000 records, so if java try :

"SELECT * FROM Item WHERE item = '999999999'"...

How does HXTT to find this quickly without indices ?
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-05-06 17:04:33.0
>this should be slower ???.
Yeah. You should descript what's your want. Then we can find a solution for you.

>>But you wish Foxplus can do exclusvie reindex when HXTT DBF is doing read-only operation without lock?
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-05-06 18:02:41.0
We wish that when HXTT execute some query like "SELECT ....FROM...WHERE field = [value]" for read only, foxplus can use exclusive same table for update, or insert record....

With lockTimeout property set to 120, we solve reindex under foxplus.....

With "SELECT recno(), _lockFlag_, * FROM [table] where recno() = 1" we solve some lock issue under foxplus

Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-05-06 23:10:40.0
Please download the latest version. For Connecgtion.setReadonly(true) or
Statement stmt = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY );

it will open it on read-only mode, and allow EXCLUSIVE table by Foxplus.

You need lockType=FOXBASE4UNIX.

You needn't loadIndices=false .
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-05-07 05:21:20.0
It means that we can use cgp files too ?, in order to optimize time to find recodrs ???

Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-05-07 05:59:56.0
Last package was published at Apr 23 ???

Thanks
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-05-07 06:06:39.0
>It means that we can use cgp files too ?, in order to optimize time to find recodrs ???
Yeah.

It should be DBF_JDBC30.jar at May 6th, 2012.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-05-07 06:16:51.0
I only can see release date : 2012-04-23 07:38
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-05-07 06:23:29.0
What's your download mailbox?
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-05-07 06:26:32.0
Our download mailbox is from our customer : *@fergi.*
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
HXTT Support
2012-05-07 06:39:59.0
Checked. That support period is expired, and need to renew its license. I have extended it so that you can download the latest version.
Re:Re:Re:Re:Re:Re:Re:Re:HXTT Crash
Oscar San Martin
2012-05-07 06:49:19.0
Downloaded and testing...

We'll renew license soon, but we 're very concerned about HXTT stability on foxplus/unix.

our client has not kept enabled java application for a long time since the index problems have forced us to go back...to foxplus app


Thanks,

Search Key   Search by Last 50 Questions




Google
 

Email: webmaster@hxtt.com
Copyright © 2003-2019 Heng Xing Tian Tai Lab of Xi'an City. | All Rights Reserved. | Privacy | Legal | Sitemap