LEGACY ALERT - This is for Delphi 5 code. (I know it is super old. It is scheduled to be rewritten.... Some day.)
I am using the BDE and the TStoredProc object. When I call Close, this normally clears my dataset. However, I am seeing weird things happen so I thought I would ask this question.
If I have manually added rows to the dataset (i.e. via the Append method) then when I call close are they going to be deleted as well?
Not sure with D5 and BDE, but I would say that you have to do an explicit Post to ensure the added record is actually stored.
if you dont post they should be getting deleted
Related
I am using IdHTTP.Post in my application to upload data to a server in the cloud. A DLL in the cloud saves the data to a SQL server database, and returns a simple message back to the application.
The uploaded data is simply a bunch of long strings uploaded in a loop (won't go into why here). Each string in the loop is pretty much always the same length.
For example:
For I:=1 to 10 do
begin
...
Reply:=IdHTTP.Post(URL,String);
...
end;
This works perfectly well 98% of the time. Sometimes, when the loop is more than 100 say, then 'Reply' will be blank. If I try again, then it works fine.
I tried various things, one of which is to add
Sleep(2000);
after each iteration of the loop, this also seems to do the trick!
So, in short, my upload seems to be tying itself into a knot every now and then when the upload is on the large size. Any recommendations as to how to handle this better than 'Sleep' would be appreciated.
I have not made any changes to the IdHTTP component from the default settings, apart from:
IdHTTP.ConnectTimeout:=5000;
IdHTTP.ReadTimeout :=5000;
I am using Delphi 2010.
Note that the string lengths are the same for each iteration, whether I am looping 10 times, or 100 times. So the string length itself does not seem to be the issue.
Update
So ignore pretty much most of what I thought was happening above. #Remy Lebeau correctly identified that the problem was that the reply was not being decoded correctly, and that is because IdHTTPOptions.[hoForceEncodeParams] was set to false.
The reason for this is outlined in a previous question:
Delphi TIdHTTP POST does not encode plus sign
#Remy, my version of Indy, as you pointed out in the old question, and in response to this one, is certainly outdated. I was a bit hesitant to install a later version as the install instructions looked a bit scary, and so I opted to encode manually instead in the meantime. This looks to have backfired, so will look at it now for sure.
At least now I know what is causing my problem.
I have a few follow up questions that you might be able to help me with:
I think I might be doing something wrong, but even if I set hoForceEncodeParams to True or False on the component, when looking at Fiddler, it doesn't always seem to be consistent in terms of the encoding going through to the server. I have only picked this up now because I'm looking at it in detail. The only way to be SURE of the encoding either way is to set it in the code right before posting, in other words ignore the setting on the component. Can this be correct, or what am I missing? This is why I understood the problem incorrectly in the first place, as the encoding was correct on the first iteration of the loop, but then inexplicably changed on the subsequent iterations.
With a IdHTTP.Get, I DO get a reply even if hoForceEncodeParams is set to false. Does this make sense?
I'm using miniprofiler and noticed that immediately after a rebuild it's giving me a crazy number of sql calls (485).
But the next time I call the page it seems to be caching / re-reading the result, because the call times are minimal. However the sql calls have reduced to a reasonable number (3). Also this seems to be a new occurance but I can't pinpoint when it started exactly.
Therefore I'm confused as to whether or not I have a problem. Does anybody know if this pertains to the rebuild and can I safely ignore it?
Or is it something I should investigate further?
Looks like MiniProfiler is recording all of the db calls made when you are attempting to drop and recreate the database.
If you don't want to record these and still want to profile that request, then try using the Ignore command in MiniProfiler.
using (MiniProfiler.Current.Ignore())
{
DbDatabase.SetInitializer<MyDBContext>(
new DropCreateDatabaseIfModelChanges<MyDBContext>());
DbDatabase.Initialize(false);
}
Include the Initialize function call within the Ignore block in order to make sure that initialization happens when you want it to happen.
JvDataSource has an OnRecordChanged event which, as the name suggests, should be fired whenever current record is changed. But it doesn't fire at all. In fact, even OnUpdateData isn't fired at all. I'm beginning to suspect that something is really wrong with either my JVCL installation, or JvDataSource component. Even a fresh installation didn't solve the mentioned problems. Is anyone out there using JvDataSource in their applications at all? And, if yes, have you ever observed such behavior?
PS: Before you ask, I have tried all combinations of DisableEventsOnLoading, and EventsEnabled.
Thanks to Sertac. It was a misunderstanding on my part. OnRecordChanged is called whenever the record is edited.
Backstory
This afternoon, I replied to a text from my girlfriend, then apparently neglected to sleep my phone before putting it back in my pocket. When I pulled it back out a few minutes later, my phone had decided to hit "Edit->Clear All" on the conversation, vaporizing two years and two phones worth of SMS history with her. While I have a backup of the phone, it's close to three weeks old at this point, and there's enough solid discussion that I'd like to reconstruct; I've already grabbed a copy of sms.db, but I think the method I used vacuumed the file, so there are no soft-deleted texts in it.
Meat of the Question
I have a three-week old backup of my sms.db, and have access to date copy of her sms.db. I'd like to
export the texts she has but I don't (easy, at least to CSV)
change the "perspective" info (the address field and the sent/received/deleted/unknown field), keeping the timestamp and text
import/merge these new entries into my old sms.db backup
merge this updated backup with my current sms.db (optional/there seems to be an online utility for that)
I don't really know SQL but would be willing to learn; the problem I have is that from what I understand, the tables within sms.db have become more interdependent over the OS's lifespan, and the triggers now call C functions that don't exist outside the phone, so it's not a simple matter of calling a single trigger on multiple entries. Does anyone know of any ways to work around this complexity, or even better, any utilities that have already figured out how to import individual entries into sms.db?
Edit:
I've been examining sms.db, and from what I can tell, the relationships are pretty straightforward:
for message, I need to mostly make sure that the ROWID of any added messages are higher than the current highest ROWID
msg_group holds the message:ROWID of the last message for each contact; I can lookup the correct address within group_member; group_member:group_id corresponds with msg_group:ROWID
msg_group has a hash column; this will probably be the hardest thing to update, since I'm not immediately sure what it's updating, or what hash to use
sqlite_sequencedoesn't seem like it's quite up-to-date; its entries seem to all be smaller than the actual ROWIDs, but I assume this means I won't have to mess with it very much.
I'm not really sure that I'll be able to change msg_pieces at all: it's the table in charge of handling the multiple parts of an MMS message.
Hey did you get this sorted out? if you haven't I suggest taking a look at http://smsmerge.homedns.org/
I have been in a similar position as you have, but I was lucky and had a more recent backup than that.
Let me know if you need a hand with it
I have a problem I cannot solve. Of course here I just expect to have a suggestion that can help me to find a solution.
Basically my application is full of runtime generated TPopupMenuItems (while all the TPopupMenus are hardcoded). In some cases what I do is simply hide/show or enable/disable items, in other cases I create items at runtime.
In some machines only, after leaving the application running for days (2 or more) the popupmenus don't work anymore correctly.
The behaviour is:
all the TPopupmenu items look are the same, and execute the same action.
The action is the one performed by the first TPopupMenuItem of the application (the first generated at runtime when the application starts, this is the only hint I have).
Imagine in correct scenario I have (in a 3-items-TPopupMenu):
Item23
Item24
Item25
after the problem I see:
Item1
Item1
Item1
(where Item1 is the TPopupMenuItem belonging to another TPopupMenu).
Does this tell you something?
Thanks.
Update:
I tried to look at the code of my popupmenus and I found what could be a common cause, and this explains also why FastMM4 didn't find this:
while mnuItem.Count > 0 do
mnuItem.Delete(0);
Delete (I just read in the documentation) doesn't free the item, I should call free instead. Anyway when closing the application the main popupmenus are freed correctly, and FastMM4 doesn't complain. So this is probably the solution, now I don't know why Delete was used, I didn't write that code.
Further update:
I tried to make a sample application, I couldn't reproduce the problem, but for sure I noticed that using this is much more performant (I tried a loop with 10000 recursions):
while mnuItem.Count > 0 do
mnuItem.Items[0].Free;
I will try for this in my app (but I need to let some days pass to really know if I got the problem, ayway for sure this is a major improvement anyway).
I confirm that the problem was linked to Delete instead of Free. Popupmenu wsa refreshed every minute on the machines that had the problem (so it was not OS or HW specific, just config specific). Then according to user settings the menu could have 10 to 100 items, so leaving it idle for days made it possible to hit the handle limit.
By the way it also makes no sense to refresh the popupmenu in that way, so I found also an optimizaion removed a bug.
Did you check for memory leakage and handles that aren't freed?