Hello Przemek
Przemyslaw Czerpak-2 wrote:
>
> I can only guess that you do not make full clean build and you
> are still uses some DBF* RDDs binaries compiled with older header
> files without some new DBFAREA members.
> It's also possible that you reached such effect by mixing header files
> from older and current Harbour versions.
>
I tried these procedures [ BCC55 - Using Since Ages]:
1. Removed sub-folders and files in harbour folder.
2. Updated from SVN afresh as a clean slate.
3. c:\harbour>make_gnu.bat clean
4. c:\harbour>make_gnu.bat install >log-%HB_COMPILER% 2>&1
5. Harbour builds perfectly as I checked the log twice.
6. Rebuild all my libraries and application.
7. The first instance executed as expected without any bumps.
8. Second instance [ same behavior with 2nd terminal also ]
put into never ending loop - cpu 50% - appln seems active.
9 Procedure 1 : No results.
Appln reaches well to the point where this table is opened.
Before this point there are many tables which are opened successfully.
The I looked into what is the difference in opening sequence of
this particular table. I found that this table is opened twice, first time
with EXCLUSIVE use, then is closed, and then opened in SHARED mode,
then DbRelease()d.
Then I commented out code where table is opened in EXCLUSIVE mode.
It means now it was being opened once and in SHARED mode. And voila
I was able to run any number of instances, no problems. BUT this is not
an option for me as I do some cleanups etc when first user is entering.
I tried another method.
I opened this table wth Foxpro in shared mode from Foxpro's command
window. Then I executed appln with EXCLUSIVE routine intact. The first
instance itself displayed the hung behavior.
Then I peeped into source/rdd/dbcmd.c : DBUSEARE() function.
I put check points as follows:
HB_FUNC( DBUSEAREA )
{
BOOL bOpened;
hb_ToOutDebug( "DBUSEAREA: %s", hb_parc( 3 ) );
bOpened = hb_rddOpenTable( hb_parc( 3 ), hb_parc( 2 ),
hb_parl( 1 ) ? 0 : hb_rddGetCurrentWorkAreaNumber(),
hb_parc( 4 ), ISLOG( 5 ) ? hb_parl( 5 ) : !hb_setGetExclusive(),
hb_parl( 6 ), hb_parc( 7 ), hb_parnl( 8 ), NULL, NULL ) ;
hb_retl( bOpened == HB_SUCCESS );
hb_ToOutDebug( "DBUSEAREA: %s Opened=%i", hb_parc( 3 ), bOpened );
}
DBUSEAREA() reported correctly and it seems funtion
returned normally, but I could never see next command
executed where DbUseArea() has been called.
> Anyhow it does not seems to be Harbour problem but rather sth wrong
> with your local builds.
>
I agree to this point but what has went terribly wrong with my builds,
I am trying to fiigure out. In view of above procedure I adopted to
debug can you guide me what else I should do to recover from it.
Any tips will be helpful.
>It's also possible that you used BMDBFCDX before it was updated.
No, never. Only DBFCDX.
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/MT---DBFCDX---Next-Appln-Instance-Hangs-...-tp23352456p23399380.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
