|
Thanks, David! I'm hoping for easy, a little paint here, and bit of wiring there, and done. I'm retired, and don't have time for too much. 
Will Rogers never met me.
|
|
|
|
|
You are welcome! Actually, thinking back on it, I believe I was a bit wrong. You don't have to copy everything to another directory - just any files you want to modify. Hope it goes well. There are other sources around with more details. A google of "modifying wordpress themes" unveils some. Also look into iThemes security and Bulletproof security for locking down your site.
|
|
|
|
|
You get quite a lot of customizability from the basic themes without having to do any coding or css work. Go into 'Appearance -> Customize' and play around!
|
|
|
|
|
Most likely your web site host will have a number of blog engines you can install.
From there you can use the templates that allow you to add blog posts.
I know you said WordPress but I can't stand by and allow it without saying anything. 
I used WP a long time ago and kept security updates and then it was compromised.
Since then I've used either DasBlog (.NET based) or the one I'm using now and I highly recommend : BlogEngineDotNet BEDN.
Check and see if your web host supports BEDN and if it does I'm sure you'll find it super easy to use.
However, I do openly admit there are numerous more WP plugins and if you need those I understand.
Good luck.
|
|
|
|
|
Actually, they don't; Wordpress is all we get. But they have a full range of plugins available. I just have no idea how to put them all together.
Will Rogers never met me.
|
|
|
|
|
|
Darn, I wish I'd seen that before they committed to a hosting service. Thanks, though!
Will Rogers never met me.
|
|
|
|
|
Hi All,
Thought I mutter about being in the orfice late(ish) on a Friday typically POETS day. I got in late as I had a bed interface issue this am. I must stay a bit longer to make up the hour late this am, I can't get any further with the test I was doing as I have come across an issue that has stopped me dead. Until this bug gets cured I can't get any further... I have spent an hour trying to operate the various time sheets we have use, internal, external, government project, private project, internal tasks?, All this as the previous time sheet could be filled in quickly. I have run out of things to do!...  Friday afternoon is pointless...
|
|
|
|
|
"bed interface issue"
You should trade mark that
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Same over here, had to stay an extra hour on thursday and friday because of the "ISO certification".
And guess what ? no ISO inspectors to be seen on our development department 
|
|
|
|
|
A longtime customer of mine recently switched receiving/inventory software and was having trouble reconciling between a specific report from the new system against values that my software imports. For some reason we have imported almost $300K more that their report shows for last month. Of course the assumption is that my import is wrong. The customer is unhappy, my colleague who has been trying to figure this out for a couple of days now is unhappy and they decide that I should get involved which makes me unhappy. 
Narrowing the focus, it became clear that the records their report is missing all fall on the ending day of the month. Looking closer, those missing records actually all have a datetime of 2018-09-30 23:59:59:000. Further, the time part of the datetime field for all records is either all 0s or maxed. 
Getting back to the source system and the report in question, I set the ending date to 2018-10-01 and viola, there are the missing records, however they are showing a date of 9/30 in the report. Interesting...now run the report for just 10/1 and they are gone. OK, got it...somebody forgot to make the ending date inclusive! 
I explain this all to the customer...my numbers are right, yours are wrong and here's why, along with 'you need to show this to the other software vendor'. Instead, they asked if I would send an email with the explanation that they could share with management and the other vendor. (so wtf did I just spend 15 minutes explaining it! ) Sensing that I was about to say something sarcastic, my colleague agreed to do it...of course I had to explain it all over again and basically dictate the message anyway. That's almost 2 hours spent chasing problems in someone else's software. Can I please just work on my own stuff now? 
"Go forth into the source" - Neal Morse
|
|
|
|
|
"somebody forgot to make the ending date inclusive!"
This is correct behavior. Personally, I can't stand SQL's BETWEEN behavior.
|
|
|
|
|
PIEBALDconsult wrote: This is correct behavior.
Really, explain that to the customer that expects to see transactions that occurred at any time on the ending date they selected.
You are correct in terms of a SQL query, but not from a UI perspective. My habit when filtering on a single datetime field is to use BETWEEN and apply the max time to the ending date. This is why my import was correct. The problem is with the other vendors report and there's nothing I can do about it. Even advising them to simply extend the ending date by a day will not work because most records simply have all 0s as the time part. The ball is in their court.
"Go forth into the source" - Neal Morse
|
|
|
|
|
"use BETWEEN and apply the max time to the ending date."
No, that's very bad, you can't be sure that the end time you choose is "max enough".
The correct implemention is to set the end time to 00:00 the following day and remain exclusive.
|
|
|
|
|
PIEBALDconsult wrote: The correct implemention is to set the end time to 00:00 the following day and remain exclusive.
Right, but then I can't use Between which means more typing...all for the tradeoff of not worrying about maybe 1 transaction in a million years might actually hit in that precise millisecond!  Anyway, good point!
"Go forth into the source" - Neal Morse
|
|
|
|
|
If your looking to report on days, use days! I.e. "between convert(date,start_dt) and convert(date,end_dt)"
|
|
|
|
|
I don't know if this is a factor in this case, but don't forget that everybody also has to agree on timezone details. Bad assumptions about timezone offsets are enough to get the first (or last) couple of records for a given day to be dropped.
|
|
|
|
|
dandy72 wrote: timezone details.
Not a factor in this case, all reporting 68 reporting sites are in the same TZ and as mentioned, this vendor uses a datetime field which is not actual time recorded, but either with the time truncated (all 0s) or maxed, depending on which process created the record.
Also not a factor, DST!
"Go forth into the source" - Neal Morse
|
|
|
|
|
Good man. That can add an extra layer of complexity.
|
|
|
|
|
Are you saying they had 300K worth of orders in the second between 2018-09-30 23:59:59:000 and 2018-10-01 00:00:00:000?
modified 20-Oct-19 21:02pm.
|
|
|
|
|
No, I'm saying the time part of the datetime is made up. In their case, as mentioned, it's either all 0s or 23:59:59.000.
"Go forth into the source" - Neal Morse
|
|
|
|
|
Yup. Vendors change their protocols and now I/we have to wallow in their filth.
As an aside - if you can get away with it, CAST(your_datetime, DATE) for your range and tests, as appropriate (going forward) and, for a little while, you've outsmarted them.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos wrote: if you can get away with it,
Unfortunately, it's not my system so I can't change their report/query, and would rightly refuse to do so if asked.
It's a minor error, but they are a large company...it could take months to get it fixed!
"Go forth into the source" - Neal Morse
|
|
|
|
|
kmoorevs wrote: A longtime customer of mine recently switched receiving/inventory software and was having trouble reconciling between a specific report from the new system against values that my software imports
...
they asked if I would send an email with the explanation that they could share with management and the other vendor
Ya done the right thing (mostly), but honestly, it wasn't your responsibility to debug the other vendor's software. Your responsibility ended at the point of telling the customer that a manual check of the data showed that your report was correct and the new vendor's one was in error.
Part of what that customer needs to know, is what the experience is like with the new vendor when their stuff is in error. They also need to know they can trust that the new vendor got things done right the first time. You robbed them of that. If that new vendor can't get basic stuff like this right, and especially if they need someone outside their company to tell them what they did wrong, then that customer should probably be reconsidering using that new vendor. Which they won't do if things go smoothly when they were not smooth.
BTW, it sounds like you actually went to the point of telling the new vendor how they processed the data wrong. If so, than that was slightly irresponsible of you -- without access to their code and test suite, you can't be sure that what you identified is their actual problem.
|
|
|
|
|
patbob wrote: without access to their code and test suite
Well, it was on a remote, initiated by the customer, and using their compiled product. Our product uses an account with read-only access to their database. We have had a relationship/agreement with this vendor for years and actually recommended them. Our product (like all of our direct connect imports) contains a query viewer for exporting and for troubleshooting just these type of issues. I modified our query to expose the time parts and just put 2 and 2 together.
Also, I only found their problem from investigating what everyone assumed was my problem. I was playing defense not offense. I didn't actually tell them how to fix their problem, only the steps required to duplicate the issue and my observation that the missing transactions have a time part and the others don't...a free clue.
"Go forth into the source" - Neal Morse
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
