You should use only one connection.
If you set a connection string on a ADOQuery or ADOCommand then the VCL will generate a new hidden connection in the background for the component.
Each connection has it's own cache inside of the driver (jet engine) for the access database.
If you modify the database through one connection the other connection will not see this change immediatly.
It needs about 6 to 10s to write the changes to the *.mdb file.
After that the other connection has the opportunity to read the changes.
==> allways use only one connection (TADOConnection)
Want to send a jpeg as an attachment without using file folder to save the attachment temporarily.
Is it possible to insert the jpeg file from application inside the message body as OLE? If yes, how to do this?
I'm writing an opc client in delphi and I'm having some problems with the ondatachange event. It is giving me an event failed with error code 0x80010105. It would appear that when i'm busy with handling an event i'm getting the next and then i'll get an error.
My question is does anybody know how I can possibly solve this?
Thank you for the answer, but it was actually an error in my client program that handled a datachange event wrong. so that the received arrays went out of bounds or the values that I got back were handled worng.
I have an application that is sending commands that are being added to a queue to a connected device. There are times when I need to send a command right away, so I need a way to add an object to the front of the queue so that the command gets sent right away instead of having it added to the end of the queue. Does anyone know how to do this? I am using a TQueue object.
I have some code which leaks memory (it's pretty much copied straight from Rudy's Delphi Corner). I have found the line that which causes the problem, but I don't understand why it's leaking which makes me concerned. I am reluctant to just fix it without knowing what's actually wrong.
The purpose of the code is to create a separate copy of a TVarRec variable. Here goes:
function TfrmMain.CopyVarRec(const Item: TVarRec): TVarRec;
// Copy entire TVarRec first.
Result := Item;
// Now handle special cases.
case Item.VType of
Result.VExtended^ := Item.VExtended^;
Result.VPChar := StrNew(Item.VPChar);
// A little trickier: casting to string will ensure
// reference counting is done properly.
// Nil out first, so no attempt to decrement
// reference count.
Result.VAnsiString := nil;
string(Result.VAnsiString) := string(Item.VAnsiString);
The following function is then used to free the copied TVarRec:
// TVarRecs created by CopyVarRec must be finalized with this function.
// You should not use it on other TVarRecs.
procedure TfrmMain.FinalizeVarRec(var Item: TVarRec);
case Item.VType of
// vtAnsiString uses reference counting.
Item.VInteger := 0;
The above code leaks memory when the TVarRec contains an AnsiString, that is in the vtAnsiString case of the CopyVarRec function. The weird thing is, the memory leak goes away if I remove the line
Result.VAnsiString := nil;
before assigning the Item's string to teh string of the the Result. If I remove it, the memory leak goes away and (it appears) the program works fine, but I really don't feel comfortable doing so without understanding why that line causes the problem to begin with.
The line which nils the Result's pointer to the string is needed, because otherwise the code which copies the string will cause the strings reference counter to decrease to 0, freeing the string. This is why the application "stopped" leaking memory when the nil-ing row was removed.
Instead, FinalizeVarRec needed to actually set the AnsiString to the empty string too, to make sure the string was freed. I believed taht would be handled by the reference counting, but it doesn't work that way for pointers.
I'm considering going back to school, in order to learn to program. The potential teacher wants to see a quick demonstration of the software that I have written in the past. Unfortunately, those require Interbase 6.
I would highly recommend using FireBird 1.5.x instead of Interbase 6.0.
It is 100% compatible but is better in every aspect.
(not to mention that FireBird is still in development, while Internase 6.0 was canceled long time ago)
Your project is using these external components - TXiProgressBar, TFreeButton, TAdvStringGrid, TdxCheckbox, TZipForge, which are not found in the RAR file you've posted. You definitely need these components to build the project. I could get TFreeButton on the Internet, and could build the component. For TZipForge, I could get the installer on the net. However, I could not get the remaining three components. If possible, you should perhaps contact the original developer, who should certainly have these components with him/her. Alternatively, you could modify the project to use equivalent components available with standard Delphi 7 and use them.
Last Visit: 7-Dec-19 1:24 Last Update: 7-Dec-19 1:24