Click here to Skip to main content
15,890,882 members

Comments by Tino Fourie (Top 79 by date)

Tino Fourie 30-Jun-20 19:09pm View    
Old post I know, but you got me back on track. My code was working great and today I made quite a few changes all over. After that I got that damn messages and I could not figure out what the hell I did. I searched StackExchange for many hours and there were many a solution which included another 5 days coding just to fix it. So simple!! Not sure what they are smoking there but it aint good. +5 to you Richard!! +5 to OP for asking the question.
Tino Fourie 7-Feb-19 5:19am View    
My apologies for the late reply - I was waiting 2 days for replies myself.

I was advised to look into Analytic Functions - LEAD and LAG, however it was a little over my head (and still is) the basic sample code I tried did not work at all and MySQL Workbench does not provide clear debug messages.

Thank you for the , I will certainly look into that.
Tino Fourie 7-Feb-19 5:13am View    
Hi Maciej, thanks for your comment.

The appID is the PK however, it will be pointless to even consider the appID because I can have sequential appID's but non-sequential time periods.

appID = INT(11) AUTO INCREMENT
appStartTime = DateTime (2019-01-01 10:00:00)
appEndTime = DateTime (2019-01-01 10:15:00)

I am indeed looking for times where a resources is not booked, however the user will not be able to see if a resource is booked or not because the type of booking will determine what the time period will be between the appStartTime and appEndTime.
Tino Fourie 2-Feb-19 11:24am View    
Hi WGC, my apologies for the late reply.

I totally agree with you on your suggestion of implementing a timestamp field. In my approach I have such a field specifically used for the BackGroundWorker when retrieving messages. I have set the BackGroundWorker to fetch messages every 5 sec, which means that my MySQL Stores Procedure will only look for messages that is 5000ms younger than NOW().

Thanks for your reply.
Tino Fourie 12-Nov-18 13:01pm View    
Hi Richard MacCutchan, thanks you for your input.

Alas, I initially went with 2 tables: one for SentMsgs and the other for RecvMsgs. I reconsidered because it would make no sense to be honest because both tables would be a 100% duplicate of the other because they store the same data, except for the SenderId and the RecipientId.

You could argue that 10,000 msgs will take longer to process (relatively speaking ofc) than processing say 1,000 messages. That is a strong argument in an environment where you have no control over the age of messages. I am however considering to remove messages older than 21 days (3 weeks). Not sure how well received it will be.... but then again, use you email instead.