Dan, are you allowed to distribute MIDAS.dll?

Sure. MIDAS.DLL is freely redistributable (redployable?). My position has always been if Borland is going to have a problem with me just distributing the DLL, then I'll write a simple single-tier app that uses a ClientDataset - which means I will need to redistribute MIDAS.DLL. That was what John Kaster and I agreed upon ages ago when I started doing this, and with MIDAS now being royalty-free, there is even less concern from my perspective.



Of course, if Borland would just make MIDAS.DLL available from their web site, I could get out of the "Hosting MIDAS.DLL" business altogether. :-)

That's all the fixes? Sheesh. If that's all Borland is going to do, I'm going back to Logo.



[Pen up]

:-) You crack me up, Chris.

Virtually all of the fixes to midas.dll came directly from reports and test cases in QC. If you look at the readme file you can see that most of the DataSnap entries have the QC number as well. So yes, absolutely it is working!



I entered comments into Raid about where the fix was made (midas.dll only or vcl only or both) and Dave aggregated that back into QC and the list you and he posted.

New bug introduced in D7.1 : see the QC report # 8101. It's a serious bug when you work with two levels of nested datasets.

I'm using a special TClientDataSet component based on yours from the incremental fetching sample. With Delphi 7.1 I found a problem: I'm using a DBGrid to show data. With a resolution of 1024x768 the DBGrid can display 30 or 31 records, depending on the horizontal scrollbar. So I decided to use 30 as PacketRecords value. To refresh data I close and open the ClientDataSet but this generates a Key Violation error when DBGrid is showing more than 30 records at once (31 - so the ClientDataSet has to fetch 2 packets). The error is raised when fetching the second packet.

Whe opening the ClientDataSet for the first time everyting works ok.

I have fixed the problem and I want you to take a look to the solution. This is the code: (my lines with //#PR)



function TDSClientDataSet.DoGetRecords(Count: Integer;

out RecsOut: Integer; Options: Integer; const CommandText: WideString;

Params: OleVariant): OleVariant;

var

OwnerData, v: OleVariant;

iRecordCount: integer; //#PR

begin

iRecordCount := 0; //#PR

if Assigned(DSCursor) then // #PR

Check(DSCursor.GetRecordCount(iRecordCount)); //#PR

if (not Active and (iRecordCount = 0)) or //#PR

(grReset in TGetRecordOptions(Byte(Options))) then //#PR

// if not Active or (grReset in TGetRecordOptions(Byte(Options))) then

ResetIncFetch;

DoBeforeGetRecords(OwnerData);

if ((not Active) and (Count > 0))

or (Active and not ProviderEOF) then

PutIncFetchVar(OwnerData, MakeIncFetchVar(FIncFetchFields, FIncFetchValues));

Result := AppServer.AS_GetRecords(ProviderName, Count, RecsOut, Options,

CommandText, Params, OwnerData);

UnPackParams(Params, Self.Params);

v := ExtractIncFetchVar(OwnerData);

if VarIsArray(v) then

begin

FIncFetchFields := v[1];

FIncFetchValues := v[2];

end;

DoAfterGetRecords(OwnerData);

end;



For the second packet (not the firt time you open the ClientDataSet) the value of Active is False so ResetIncFetch is called and the value of FIncFetchValues is Unassigned when calling PutIncFecthVar.



Thanks, Pablo Reyes

preyes@excite.com

I am using MS SQL Server 2000...

When I try to locate a record in the database using KEYVALUE more then 255 CHAR the locate function dose not work. and alwayes return false...

Hello all,



I am working on an old project written by others in D5 and is extended by

me. The program works fine when compiled in D5.

I decided to upgrade the whole project in Delphi 7 (also all updates of D7

have been installed) in the hope to get the last improvements made by

Borland.



After changing some small things like including variants in my uses lists

and converting the parameters in functions like OnReconcileError i was able

to compile the application in D7. At first the application seemed to work

fine. Unfortunatelly doing some more tests i got AV exceptions in the

following situations:



At FreeAndNil of 2 datamodules i get the error "Privileged instruction" or

just access violations.

After doing some debugging i found out that something goes wrong on

ApplyUpdates(-1) of the clientdatasets that are in these datamodules.

Remarking ApplyUpdates(-1) solves the problem but doesn't save of cource in

the Database (ORACLE 9i)!!



All of the ClientDatasets are connected to providers and the providers to

Sql queries, are using NestedDatasets, Internal calculated fieles and

aggregate fields.



In one of the datamodules it was relative easy to change the structure of

the nestedDatasets in Master-Detail relationships which actually didn't

solve the problem. Also i tried to change the order that the objects of the

datamodules are getting freed. No difference. I wrote an onFree handler

where i destroyed the objects alone. For some uknown reasons to me some

objects are pointing to nothing or to wrong addresses. So trying to free

them gives the "privileged instruction" exception or an AV. Changing the

order when the objects of the datamodule are getting freed just destroyed

other ones. An idea of mine is that maybe something internally on the

ClientDataset is writting over the address space of some other objects. I

took a better look at the code written in the ClientDatasets by my old

colleges (events and so on) in the hope to find some buggy memory

allocations or buggy use of pointers. Nothing there...



So i done the following. I created new ClientDatasets and i build them

exactly as the old ones (100% exactly). After throwing away the old ones and

renaming the new ones in the name of the old ones i didn't get again the

exceptions from this datamodule. Well it seems that it works fine but i am

not sure if this will be stable enough after some time!? And of course this

is not a workaround in such a big project.



The 2. datamodule has so many ClientDatasets so that i can not do it in the

same way and of course i am not sure that it will solve the problem!.



So before starting investing so much time on this i would like to ask the

following :



1) Is there a known bug in the last update of Delphi in TClientDatasets on

ApplyUpdates which match my situation?

2) Is there a workaround that i can do in order to solve my problem or do i

have to remake the whole datamodules?

3) After remaking the datamodules can somebody be sure that the program will

be stable enough in order to give it in our clients or could happen that at

first the problem is solved but sometimes it crashes ?



I would be very pleased if someone could give me an answer.



Thanks in advance

Kostas

When applying updates from the client, i get this error: Record not found or Changed by another user.

When applying updates from the client, i get this error: Record not found or Changed by another user.

error midas with dbexpress

dsfdfdf

When using more than 13 (15 in Delphi7) nested datasets in TClientDataSet in any order (sequentally or in "one layer") occurs an error "Operation not applicable" when saving data.