Devart Forums

PaulT2

I know it's 12 months later Andrey, but your answer also directly helped me understand the same error.

We're also using Remobjects, but already using a TROPerClientClassFactory. The problem was basically the same though. The TROPerClientClassFactory was being destoryed on the server, the client later made a call, creating a new one. The first call made on the new class factory instance was the .StartTransaction on a non active TMSConnection.

Our underlying problem is one of not being stateless, which is an architectual issue going back over 10 years now...

Paul.

PaulT2

Thank you. That's working fine now. Looking like a great addition to the DAC family and very timely for us. We'll be ordering shortly.

PaulT2

Your new DAC came along just as we were about to buy an alternative, but as we already use SDAC and PgDAC we'd much prefer to keep everything in one place. I have a work around for this problem, but is it a bug in TDAParam, or something I'm missing ?

I've always used TField / TParam variable shortcuts wherever possible so as to save multiple FieldByName / ParamByName lookups when dealing with multiple records. I'd prefer to keep doing that, but at the moment, the only to get the blob field populated seems to be via the ParamByName method for each record I want to create.

Code: Select all

procedure TClientData.CreatePart(const aFileName,aName:string ; const aId:integer);
var pId       : TParam;
    pName     : TParam;
    pPicture  : TParam;
    Stream    : TFileStream;
begin
     Stream := TFileStream.Create(aFileName,fmOpenRead);
     LiteQuery.SQL.Clear;
     LiteQuery.SQL.Add('insert into Part (Id,Name,Picture) values (:Id,:Name,:Picture)');
     pId      := LiteQuery.ParamByName('Id');
     pName    := LiteQuery.ParamByName('Name');
     pPicture := LiteQuery.ParamByName('Picture');
     pId.AsInteger   := aId;
     pName.AsString  := aName;

     // This works
//     LiteQuery.ParamByName('Picture').LoadFromStream(Stream,ftBlob);

     // This gives an access violation in TDAParam.GetIsNull
     pPicture.LoadFromStream(Stream,ftBlob);

     LiteQuery.Execute;
     Stream.Free;
end;

PaulT2

Thanks Andrey. Now you've explained how to duplicate the problem with ADO, I've had a look on Delphi Quality Central. For future reference, I believe this bug in Midas may already have been reported as #104240. After following your comments and duplicating the problem in ADO myself,I've added notes to the QC entry to that effect.

It doesn't help me, but a workaround if you only need read only access would appear to be to set the ReadOnly property of the TMSQuery to true. I would guess that under the hood this works because in read only, the key fields possibly do not need to be known and therefore PSGetKeyFields is not called...

Looks like we have to stick with 32 bit on the client side at the moment as I don't want to deliver Midas.DLL separately again.

PaulT2

Hi Andrey

I'm assuming you haven't reached a conclusion on the issue yet, but are you able to give me an update on where your investigation is leading ?

Are you able to see if the problem is with SDAC or Delphi? If it's the former, I know you'll get a fix relatively quickly, if it's the latter I have less faith that we'll get a fix in any meaningful time frame.

Thanks,

Paul.

PaulT2

This may be an SDAC issue, or a Delphi issue, however, using ADO components, the problem does not present. Trying to convert our key client side product to 64 bit highlighted this problem. The software is quite complex - involving RemObjects SDK, plus a good number of 3rd party components, however I've eventually managed to narrow down the circumstances and have built a clean VM to further isolate the issue.

The new development environment is a clean install of XE2 Update 4, HotFix 1, along with the latest SDAC 6.2.7. This is running under a freshly built 64 bit Windows 7 Pro VM with all current windows updates applied.

You can find a very simple sample project uploaded to YouSendIt at the URL listed below. In the zip file is also a small script to create a table in tempdb and insert a few records.

The actual problem only seems to present under the following conditions :-

1). 64 bit
2). SDAC is used (in preference to ADO)
3). MidasLib is included in the project uses clause
4). The table being accessed has a similar structure to that in the sample project. Crucially, there must be a primary key defined.

Change any one of the above elements and the problem does not show. I can only think this is either SDAC or possibly TClientDataSet related. If you're able to offer some insight I'd be grateful as this seems to be the one thing left preventing deployment of our client software under 64 bit.

http://www.yousendit.com/download/QlVpW ... 00&s=19102

PaulT2

This is just a note, possibly to myself in another 3 years time when I'm Googling the same issue again....

Yesterday we again saw an incidence of a stack overflow being triggered in the OnPutData of a TMSLoader. This time though we had access to the customers database and were able to debug the issue.

As it turns out, the problem has nothing to do with the TMSLoader component, but is ultimately a call to a TList.Sort and it's QuickSort implementation. The particular dataset going into the sort at that point would appear to be "degenerative" and cause extreme recursion of the algorithm.

We have yet to decide if a solution needs to worked out, but the problem is definately not DevArt related.

Paul.

PaulT2

Thanks for the quick response Andrey, it's much appreciated.

Paul.

PaulT2

I know update 4 has only been out 48hrs, but can you post here as and when an update to SDAC 6.1.4 that supports it is available - likewise for PgDAC. It appears that Update 4 delivers fmx162.bpl and not fmx161.bpl

Thanks,

Paul.

PaulT2

Hi Alex,

Just confirm, you should have had en email from me earlier today with a sample project attached.

Paul.

PaulT2

Using XE2 Pro Update 3 (version 16.0.4358.45540), SDAC 6.1.4 along with FastMM4 in full debug mode for 64 bit, I get error "$C0000005 with message 'c0000005 ACCESS_VIOLATION' " when trying to call VirtualTable.LoadFromStream.

This does not appear to cause a problem in production in either 32bit or 64 bit mode, but only shows itself when using the FullDebugMode of FastMM4 (I also switch on EnableMemoryLeakReporting and CheckHeapForCorruption).

Apart from the FastMM settings, all that is needed to repeat the problem is a default project with a VirtualTable component dropped on it. I then use the following commands :-

Stream := TResourceStream.Create hInstance, 'DatabaseUpdate', Types.RT_RCDATA);

VirtualTable1.IndexFieldNames := 'Major ASC; Minor ASC ; Release ASC ; Step ASC';
VirtualTable1.LoadFromStream(Stream,true);

The ACCESS_VIOLATION appears on the LoadFromStream statement.

Are you able to duplicate this ? I'm actually wondering if this is a problem in the Delphi compiler at this stage.

PaulT2

I believe this is a separate question to an earlier one I raised with regard to assertion failures (which I think we fixed after forum advice), but the two may be linked...

I'm trying to harden our server application to occurances of the network being taken down around it. So when I disable the LAN connection and try to shutdown the application, I get an assertion failure at line 4693, but as we don't have the source code edition I can't see exactly what this line is asserting...

This occurs right at the end of the application closing down i.e. after the main form destroy. In fact the call stack looks to be calling TComponet.DestroyComponents, then TMSSQL.UnPrepare and finally TCustomDASQL.EndConnection.

Any pointers in the right direction would be appreciated as always.

Paul.

PaulT2

Thanks for the response Andrey. Intermittent as it is, I suspect the problem is likely to be due to our multi threaded use. The logging I am talking about is a new feature and can be called from a number of threads. However it IS ONLY called from one thread at a time. Having said that, the TMSConnection is in the main thread and the calls are coming into the main thread from other threads.

Within those other theads we do actually have separate TMSConnections for the activity of those threads. This logging really should make use of them as you describe. I will modify the application accordingly and report back if I continue to see the problem - although at the moment the application is stubbornly refusing to throw the error in any event.

Thanks,

Paul.

PaulT2

In 6.1.4
"Assertion failure (D:\Projects\Delphi\Dac\SqlServer\Source\OLEDBAccess.pas, line 13196)"

In 6.0.1
"Assertion failure (D:\Projects\Delphi\Dac\SqlServer\Source\OLEDBAccess.pas, line 12755)"

Not having the source code version, can you point me in the right direction to work out what might be causing this. I'm sure the assertion is the same line of code in both releases...

It may very well be tied to "Command text was not set for the command object". However the SQL is most definitly set!

I've simplified the setup so that a TMSConnection is just used by the one TMSQuery. THis query is an "insert" statement (into an activity log type table). The query is setup at program start and never modified. New parameter values are set and ".Execute" called. 99% of the time, the statement works fine. This type of code is nothing out of the ordinary and such techniques have not caused problems with SDAC previously.

The only thing you may consider slightly out of the oridinary is our use of

"OLEDBAccess.ParamsInfoOldBehavior := true;"

This we have been using for the last 4 years as advised to me here :-

http://www.devart.com/forums/viewtopic. ... highlight=

I now have this code in production for a customer with an exception handler wrapped around it , so any advice would be greatly appreciated.

Paul.

PaulT2

Hello Alex,

I see from your reply that dbExpress will initially be only 32 bit. Can you give a run down of all DAC drivers and their 32 / 64 bit position in the initial Delphi XE2 release ?

From my position I'm interested specifically in SDAC , but from a quick forum search I can see others are asking about other DAC drivers too.

We're keen to get all the components we need in a 64 bit version as soon as possible. Another post I saw indicated that the release would be in "1 or 2 weeks". I don't expect a specific date from you, but I assume you're aiming to release on the same date that XE2 is released ?

Thanks,

Paul T

Devart Forums

Search found 29 matches

Re: Datasnap + Remobjects SDK

Re: TLiteQuery and TParam for blob field

TLiteQuery and TParam for blob field

Re: Access violation, 64 bit , static MidasLib

Re: Access violation, 64 bit , static MidasLib

Access violation, 64 bit , static MidasLib

Re: Version 4.35.0.14 : TMSLoader.OnPutData : Stack Overflow

Delphi XE2 Update 4 support (fmx161.bpl)

VirtualTable in 6.1.4 SDAC : $C0000005 ACCESS_VIOLATION

OLEDBAccess.pas Assertion failure line 4693 in version 6.1.4

Versions 6.0.1 thru 6.1.4 assertion failure on XE2 update 3

DAC and 64 bit