I have a winform application and a mysql server saving the data.
I created a form from which users can save/update/delete records pretty normal stuff.
The problem comes when I added the delivery time functionality where the product has a expected, standard time in which it will be delivered; so say it has a six day expected time the form would calculate the expected time and show it back to the user, straight forward.
I've tried using a DATETIME column but after reading mysql documentation it has upper and lower limits so I cant´save say '0000-00-01 12:30:00'. So how do I save that kind of data into mysql? Whats standard practice in this topic?
Related
I am in the final stages of building my website and I am getting a little nervous that I am doing something wrong with my database.
I am building a Laravel/mysql site that allows users to add events. So I have an Event database. I allow users to choose dates for their event for next six months. That means one Event can have around 180 event dates which I save to a separate database called Shows. Each of those show dates can have tickets and the prices(vip, general etc) in a Ticket database. That means for just one event, it could create a huge number of entries.
event(1) -> show on every day(180) -> 5 ticket types(900 entries in my tickets database)
As far as I can tell this is the correct way to do it, but it seems like my Ticket database is going to get massive quickly. I will be using Elastic Search to filter through the data.
I have a MySQL database running and I've got Tableau connected to it. The issue I am having is that the table is too long - it contains years of transactions. And I only care about the transactions in the most recent 60 days. I have added a filter on the date so I can get the subset I need. However, it is super slow every time I open the workbook since it will query on the whole table and then apply the filter. So my question is:
How can I make Tableau only load the most recent 60 days of data to start with? Thanks!
I see a few possible solutions :
Create a view or a materialised view in mySQL to cater for the last 60 days only
Change the sheet filter to a context filter. The (normal) sheet filter won't affect the data query, but a context filter will.
If it's still too slow, create an extract. You can schedule Tableau Server to update the extract every day.
I have a SQL Server table the contents of which I'm displaying in an MVC page using Kendo UI Grid. One of the columns in the table is named RecordDate and is a SQL Server Date type (not a datetime variant).
When my page requests data, I'll retrieve some rows, convert to Json (as shown below) and return them to the client.
return Json(resultSet, JsonRequestBehavior.AllowGet);
The problem is all the dates are off by one day when displayed in the Kendo grid. I suspect something along the way is assuming the dates are stored as UTC dates (which they are not) and then attempting to convert to local time. However, I have no idea where this is happening, why and how to stop it.
We have recently had a similar issue, there are a number of links which discuss this:
Stringify modifying dates
How to prevent modification of times
Server changing dates sent by client
Notably the best/most acceptable resolution (and one we decided to use) seems to be the use of the moment.js package to handle dates. However, as you will see throughout the links above, this is open to interpretation.
I'm working on an app that is partly an employee time clock. It's not too complex but I want to make sure I head in the right direction the first time. I currently have this table structure:
id - int
employee_id - int (fk)
timestamp - mysql timestamp
event_code - int (1 for clock in, 0 for clock out)
I've got everything working where if their last event was a "clock in" they only see the "clock out" button and visa-versa.
My problem is that we will need to run a report that shows how many hours an employee has worked in a month and also total hours during the current fiscal year (Since June 1 of the current year).
Seems like I could store clock in and outs in the same record and maybe even calculate minutes worked between the two events and store that in a column called "worked". Then I would just need to get the sum of all that column for that employee to know how much time total.
Should I keep the structure I have, move to all on one row per pair of clock in and out events, or is there a better way that I'm totally missing?
I know human error is also a big issue for time clocks since people often forget to clock in or out and I'm not sure which structure can handle that easier.
Is MySQL Timestamp a good option or should I use UNIX Timestamp?
Thanks for any advise/direction.
Rich
I would go with two tables:
One table should be simple log of what events occurred, like your existing design.
The second table contains the calculated working hours. There are columns for the logged in and logged out times and perhaps also a third column with the time difference between them precalculated.
The point is that the calculation of how many hours an employee has worked is complicated, as you mention. Employees may complain that they worked longer hours than your program reports. In this case you want to have access to the original log of all events with no information loss so that you can see and debug exactly what happened. But this raw format is slow and difficult to work with in SQL so for reporting purposes you also want the second table so that you can quickly generate reports with weekly, monthly or yearly sums.
Is MySQL Timestamp a good option or should I use UNIX Timestamp?
Timestamp is good because there are lots of MySQL functions that work well with timestamp. You might also want to consider using datetime which is very similar to timestamp.
Related
Should I use field 'datetime' or 'timestamp'?
I've got a list of clients who have certain tasks done on a weekly basis. Currently we use an excel spreadsheet that keeps track of this but I am in the works of automating it. In the process of moving this into our MS Access system, I have created a form that does this for a single day and can display a report that outputs in the manner I want the form to look but I cannot get the form to look like that so the user can see all the days of the week for all the clients at once. I suppose I could do this in a subform per client but it seems a bit messy...
The spreadsheet we currently use has Column headers that state the Date and the rows are sort of grouped up by client that are for the number of times the given action occured, the timestamp of when it happened and other various data that happened on that day.
For the life of me I cannot think of a way to view all the records for that given week, grouped in detail per client all at once on the form. I can think of some ways to do this through VBA with recordsets but would like to know is there is a simpler way to do this that is easier to maintain.
Is there a way to do this with the use of a query and a few small scale tricks that don't involve storing recordsets? Keep in mind that this is for Access 2000, I only wish we would upgrade to '03.
Why not use five subforms? One for today, another for tomorrow, etc for
the next five business days. – Tony Toews Sep 12 at 20:57
That is the answer I've gone with and it works BEAUTIFULLY with the setup we are using. Thanks for the wonderful idea!