> Przemysław Czerpak wrote: >>> I have a proposal to move ads error value to osCode and leave >>> subCode zero, if we do not return a dbf compatible error. This >>> change also allows to get more precise error description by using >>> AdsGetErrorString(), since we will know ads error in all cases. >>> Any objections? >> For me it's very good idea. > > But one problem we have... There is code: > > /* 1001 and 7008 are standard ADS Open Errors that will usually be sharing > issues */ > HB_ERRCODE errOsCode = u32RetVal == 1001 || u32RetVal == 7008 ? 32 : 0; > fRetry = commonError( pArea, EG_OPEN, ( HB_ERRCODE ) u32RetVal, errOsCode, ( > const char * ) pOpenInfo->abName, EF_CANRETRY | EF_CANDEFAULT, &pError ) == > E_RETRY; > > This interacts with default error handler behavior in errorsys. > > Sharing violation is not indicated by some error subCode and general > EDBF_OPEN_DBF is returned in dbf rdd. So, osCode is the only way to detect > sharing violation and it is hardcoded to DOS error codes. > > Perhaps we must leave this hack, or... extend default error handler to adapt > to rddads. It is also not a nice solution, because ADS is not even in core > code. > > Any proposal on this issue?
After having a closer look: Maybe the solution is to reserve osCode _always_ for some DOS error code equivalent, and consistently return ADS error codes in subCode. IOW to me the real solution looks rather like to use subCode only to return ADS specific error codes. "subCode" is a private matter of any given RDD (or library), so we don't need to be compatible with anything here. Here the only problem is that subCode is not a 32-bit value at the moment, but this one can be changed. In fact I was thinking about it in the past already. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
