I am trying to create an interactive table which can display work shifts for a given week. I wanted the table to look something like this.
I've managed to recreate something like this using VB.net, however I have done it in (what I consider to be) a ridiculous way. I have used a TableLayoutPanel with a column for each day and a row for each hour of the day. This works, looks okay, and also allows editing of shifts. (I.e, you click in a cell to turn it green and add it to a shift).
The problems with this solution are (a) there is no easy way to represent half hours, or quarter hour segments easily and (b) the fact that each cell contains a blank label which then gets coloured in, the form takes a long time (~ 6 seconds) to load, which seems unnecessary to me. What would be a better way to implement something similar to this? Preferably without using the VB reporting, since I can't seem to get that to work, though that's a separate issue.
Thanks.
Related
I have a big fat sort of table with lots of elements that make it really buggy.
For context 1 row per user, each user has X projects and each project has 3 month of day display (sort of gantt)
So I built something cool it's working great, but if I scale to more users it begin to be real buggy.
I'm implementing filter to display less users but at some point it need to handle the limit that I have now without being buggy.
What I found is when I'm updating a day it re-render the whole Gantt which is really stupid.
here is a minimal reproduction link: https://stackblitz.com/edit/vitejs-vite-g6azah?file=src%2FApp.vue&terminal=dev
As you can see when I'm updating an input with the v-model:
value.value
I have the attribute with the function
:test="testRerender()"
That trigger for the whole Gantt and I believe it is the issue here.
I saw v-memo that look like what I need but I can't figure out with the doc how can I use it to match my needs (and there is almost no good article on it)
Thanks for your help you would save my life!
I tried to filled proper :key attribute, code optimization, v-memo etc...
I've started a new job and am looking at some of their views that they wanted me to get familiar with.
One of the views that I'm going through has 54 SELECTs. I've NEVER seen such a massive View before and after browsing through it, I'm fairly certain that I can optimize it.
What I'm looking for is an easier way to compare the JOINs between each of the selects to find commonality WITHOUT just having to sift through them all by hand.
I'm fairly certain that THAT is what I'll have to do, but I was hoping that someone would have an easier or more efficient and less time consuming way to do this...
Anyone? :)
Update 12/4/2019:
TLDR; I separated each main SELECT into it's own file, then using Notepad++ on the full view code file I found common values to sort and organize each individual SELECT into a folder named the common value. From there I used WinMerge to compare each group of SELECTs in their respective folders against each other to find differences and commonalities. I then started refactoring and minimizing the excessive code (and table calls >.< ) using CTE's (because this is Oracle and a View).
I ended up splitting out the views SELECTs by looking for one of the field names that's a column in the view. This meant that I'd get the beginnings of each SELECT.
I then copied and pasted each one into a different .sql file. I also saved the full view into it's own .sql file.
Using Notepad++ I searched for each instance of the view column name and took down the column value that is the main information needed for the view. Using that information, I grouped each SELECT into a folder based on that value
Once I'd gotten all the SELECTs into their respective folders, I used WinMerge to the SELECTs to the others in their same folder. This helped me to locate commonalities and differences, some differences that would be harder to lump the datasource table into a CTE with the others.
I've since been updating, refactoring, and fixing the view one folder grouped SELECTs at a time.
The project I'm in has had me touching each one of the main code values that I had used to organize the SELECTs into folders, so I WILL end up recoding the ENTIRE view. :)
Identifying similar lines of code is a difficult problem, and as far as I know Clone Doctor is the only program that can do it for PL/SQL.
I only used it once, about 10 years ago. But I remember being surprised at how well it found different lines of code that were really duplicates at a deep level. It wasn't perfect, and had some bugs and took a while to get working. But there's a free trial version.
I have an MS Project document that was set up by someone else, previously the schedule would change the cell colour based on if a cell had been modified in the last week. but this has stopped working. ive exhausted my knowledge trying to fix this without using VBA so now I need to start learning more about VBA.
Basically what i would like to do is
If cell last modified date <7 days set colour Yellow
if cell last modified date >7 days set colour White
and ideally this would only work on a set range of cells.
I know that this is not the level of detail that most questions here have and im basically brand new to VBA, but its never too late to learn right?
For a little background the last programming i have done was 20 years ago in university when I took a basic C++ course
Im sorry to tell you that what you are asking is not exactly IMPOSSIBLE but the amount of code you would need to write to make it happen would be HUGE. Cell highlighting just tracks the LAST set of changes. There is not really a 'date rage' capability built in.
To do this would require a LOT of event code and storing stuff in custom fields and would slow application performance to a literal crawl. Also, since SO many cells across tasks are linked because of predecessor\successor links you could make a change and then it could change literally every task in the project. It would be a nightmare.
What business problem are you trying to solve with this?
I have inherited a database that's causing me issues.
I'm in the need of describing something horrible to stakeholders. So far using the names of anti patterns and sending them away pointing them to a google search on this has been the most efficent to buy me some time.
Trouble is, I have not come across this before. Here's what's happening.
I have a simple single table, with a couple of columns. One of these columns contains values like:
660x90_SomeCity_SomeCountryISO_ImageName_SomeRubbish
or
SomeIataAirportCode_SomeCountry_660x90_SomeRubbish_ImageName
Now the database contains an (admittedly so far and on current data) faultless logic to extract and lookup things so that the output has additional columns such as:
AdSize
Country
City
The trouble is that this is achieved through gradual conversions implemented in a labyrinth of 50 (not joking) different views. I've now got to formalize the logic to something like
View One: Extract the first column and work out the length of it.
View Two: Now split of the 2nd column using the length.
View Three: If after replacing the x in the first column the value is numeric, store the value in "AdSize", and place the second value in the "CityCandidateOne" column.
To me this is a horrible antipattern and should all be done either in custom functions, or preferably during the ETL process, in one place so the logic can be captured.
However I'm not being given the time and wonder if this is a known anti pattern. Usually I can then use the credibility of a Google search to buy a little time to really sort this out.
I'd start with this answer which covers the violation of First Normal Form.
I also found this free ebook that might be of value.
I understand that what you are facing is something on a grander scale that just putting a couple of values in a field with a comma or other token to separate them, but I don't know of any antipattern that covers such a baroque mess.
Finally, here you can find more about "replacing SQL logic with Views" as an antipattern (just look for "Views as SQL Building Blocks Anti-Pattern" in the article) but take in account that in this case the problem seem to be about inefficient access to the data.
Last minute edit: maybe this is just a special case of the general Golden Hammer antipattern? (see also: http://en.wikipedia.org/wiki/Golden_hammer)
Why not simply rewrite the SQL how you would rather do it, then print out the execution plans of both, and show the performance and timing of both. That should be enough to show them that it needs to change (and if there is no major performance difference, then your only other argument can be one of maintainability and that's something you're going to have to argue by showing them what it takes to make changes).
I'm working with a legacy database which due to poor management and design has had a wildgrowth of columns which never have been or are no longer beeing used.
Is it possible to some how query for column usage? As in how often a column is beeing selected (either specifically or with *, or joined on)?
Seems to me like this is something we should be able to somehow retrieve but i have been unable to find anything like this.
Greetings,
F.B. ten Kate
Unfortunately, this analysis on the DB side isn't really going to be a full answer. I've seen a LOT of instances where application code only needed 3 columns of a 10+ column table, but selected them all anyway.
Your column would still show up on a usage report in any sort of trace or profiling you did, but it still may not ACTUALLY be in use.
You might have to either a) analyze the entire collection of apps that use this website or b) start drafting the a return-on-investment style doc on whether it's worth rebuilding.
This article will give you a good idea of how to search all fixed code (prodedures, views, functions and triggers) for the columns that are used. The code in the article searches for a specific table/column combination. You could easily adapt it to run for all columns. For anything dynamically executed, you'd probably have to set up a profiler trace.
Even if you could determine whether a column had been used in the past X period of time, would that be good enough? There may be some obscure program out there that populates a column once a week, a month, a year; or once every time they click the mystery button that no one ever clicks, or to log the report that only Fred in accounting ever runs (he quit two years ago), or that gets logged to if that one rare bug happens (during daylight savings time, perhaps?)
My point is, the only way you can truly be certain that a column is absolutely not used by anything is to review everything -- every call, every line of code, every ad hoc Excel data dump, every possible contingency -- everything that references the database . As this may be all but unachievable, try to get a formally defined group of programs and procedures that must be supported, bend over backwards to make sure they are supported, and be prepared to fix things when some overlooked or forgotten piece of functionality turns up.