iirc i had this issue before but i changed a TROPooledClassFactory from PreinitializePool from FALSE to TRUE and now i get a runtime error running the serverapp..
it crashed somewhere in the create of the dataabstract service - can’t pinpoint it due to the magnificent failing of the debugger in delphi…
i do have other preinitialized DAservices that get created in the same way before the one that crashes so i have no real idea what is going on
if set to FALSE all works …
Hi,
I can’t reproduce any issues with TROPooledClassFactory.Create(...,true) and TDataAbstractService descendant in simple testcase.
probably you do some extra initialization for your DataAbstractService …
no not really…
the only thing i added is a macro function in the DataAbstractServiceAfterAcquireConnection like
var mac:IDAHasMacroProcessor;
if Supports(aAcquiredConnection, IDAHasMacroProcessor, mac) then
mac.GetMacroProcessor.RegisterProc(‘CheckBitwise’, CheckBitwise, 2);
but it never gets into that event…
Hi,
what runtime error is raised when you are using PreinitializePool = true ?
if you compile with debug configuration and these settings, error in debugger will be shown?
runtime error 217
setting those debugging properties like shown does not change a thing
i guess it crashes in reading in the dfm but there is no real change execpt for the event and allowmacros…
it crashes in procedure TReader.ReadProperty(AInstance: TPersistent);
getting there (got to the point of first exception):
‘Invalid BusinessRulesID “ServerRules.RelatieNxN”’
why is another question
Hi,
AFAIK, Delphi uses one global critical section for all TReader/TWriter calls…
try to remove BusinessRulesID from .dfm and assign BusinessRulesID in Create manually.
so it’s a matter of the which is processed first as unit, the schema or the unit in which the businessprocessor rule is defined
Hi,
try to put file with businessprocessor rule into interface section of daservice.
it should be enough
and i don’t see a way around the order of units in the dpr if you have a specific businessrules unit that registers itself if that unit hasn’t been able to register itself…
that rather limits the preinitializepool option…
setting the businessrulesid in the create event does not solve that problem
have you removed businessrulesid from .dfm ?
try to create a simple testcase that reproduces this issue
if i remove the businessrulesid from the component in design time AND the implementing unit is not streamed in before the DAservice (at which point the RegisterBusinessProcessorRules did not register the name used) AND setting the businessrulesid of the businessrules component in the DataAbstractServiceCreate event, that will result in a businessrulesID not found exception (with the advantage that that one does surface normally as an error instead of runtime error xxx
i guess it’s easy to reproduce?
that said, adding the unit that implements the businessruleid in the implementation section does remedy the problem…
Hi,
adding the unit that implements the businessruleid in the implementation section
will it also solves issue when BusinessRuleID is defined in .dfm only?
yes.
Hi,
I’m not sure that it can be fixable on our side 
We can just raise error like
You can just take a note that units with business rules should be included into uses section of services
i guess it has to do with DA code that when created checks for the existence of the implementing businessrulesid class when the component is created
potentially it could just assume that it will be present (lazy binding) instead of enforcing it, but then the error would surface at runtime
i can live with respecting the order of units, it was just really unclear what the cause was and again, the delphi debugger is quite bad to dig deep into source
