Whew! Finally got the correct code into prod and it ran like a charm. Now, what the heck was I gonna work on yesterday morning when this production issue came up and prevented me from getting started?
sProc design question: I need to get 2 related counts from 2 different tables. As far as I can think at this time, I'll always need to get both of them at the same time (i.e., I don't think I'd need one without the other). Does it make sense to write 1 sProc that returns both numbers in order to minimize round trips to the DB, or does it violate the S in SOLID to have the sProc gather 2 different numbers that way?
Question still stands, but is now purely theoretical. A smidgen of investigation reveals that I do need to get the numbers independently, so I'll write 2 sProcs. Curious for future reference, though.
SOLID doesn't really apply to the same extent to the realm of SQL and data querying. What are good ideas in imperative programming aren't necessarily so in declarative programming.
@theVBE-it'srightforme imperative is "do this the way I told you to do"
With FileOpen(FilePath)
For i = 0 To File.Lines.Count
Line = Files.Lines(i)
If Line Like "*<foo>*" Then
Do
Print File.Lines(i)
i = i + 1
Loop Until Line Like "*</foo>*"
End If
Next
End With
Contrast to declarative, which can be executed imperatively:
Print XQuery.SelectAllNodes("//foo")
note that you put in an essentially magical string ("//foo") to execute the query. Same way with SQL.
Better way to think about it is that you want to provide an API for your database. It doesn't necessarily mean letting them go in the guts and do whatever they want but rather present a model that meets the application's needs and allow the database to do the actual work of modifying the data, which could be spread across several tables.
There are essentially two approaches -- "thin database" or "fat database"
(they may have other terms)
with thin database it's just a dumb old data store. All the logic is in the middle layer somewhere.
with fat database, the middle layer (or even the client layer in 2-tiered architecture) is just calling the stored procedures and views (AKA the "API" of the database) and letting the database do the work via the stored procedures.
The thin database model will not work with a 2 layer architecture and absolutely requires a n-tiered architecture in order to abstract away the API.
But it does mean you can easily swap out one database engine for other since it's basically a CRUD thing
For me personally, I'd rather use fat database because that means we can rely on the guarantees that are provided in the databases itself (e.g. foreign key constraints, check constraints, whatever) to protect data integrity and it works with both 2-tiered and n-tiered architecture but that's just me.
"thick database" sounds much more PC. I prefer "fat database"
OK, yeah, I remember you saying something about this a few years back.
At this point, I'm klnda transitioning from thin to fat
not necessarily in a well thought out, coherent API kind of way, but starting to put more of the logic into sprocs to enforce it there. (For example, when I pull survey responses, they have to be from a given appointment date range, and completed within 10 days of the end of that range. The sproc accepts the appointment date range, but computes the max completed date on its own so I don't forget that part of it.
Well I just updated Issue #5442 because it's only happening on one of my PCs. Now I'm completely stumped as to what is causing RD to fail to produce Code Inspections. Why would this only happen on some computers?
Parsing completes, the toolbar says "Ready". The code inspection window has the spinning ducks, never shows results. Access is hammering the CPU with 50% usage continuously. I've let it run for a long time. It never finishes
Plus, it only happens on big projects. RD works fine on smaller code bases....
Such a strange issue.
It's better today, in the newer version. I can at least close Access with the close button. I don't need to force quit
Any ideas for how I could peek in to what is happening here?
Ok, I'm running ProcMon and capturing a parse
It's kinda crazy to watch, if you've never done this
wow, when the parse completes I see it write the final entries in the log and then the whole thing gets quiet. The CPU is cranking but Access isn't actually doing much
There is a shockingly high volume of registry activity towards the end of a parse. Is that something RD does or is Access just doing that?
@IvenBach oh yes. I've been using that for quite some time. I'm pretty sure it was someone here (maybe you?) who mentioned it. I quite love it, actually! (slows down browsing on occasion, but it's better than burning out my eyeballs!)
It's just nice to see SE actually bringing about changes people have been asking for. Even if it's too little, too late.
SE worker1: We're hemorrhaging users. What do we do?
SE worker2: How 'bout add a feature?
SE worker3: Yeah. Users love features. Look at Facebook!
SE worker1: Thus we have solved problems with ---DarkMode--- DorkMode.
:derp: markdown morkdown doesn't work with code blocks...
I don't trust SO the company at all anymore, but imo they seem to actually be doing a good job for whichever kind of person is still on the fence.
Teresa seems to be doing better than could be hoped even though (I expect based on history) that she'll eventually be kneecapped or her efforts will be abandoned/forgotten.
I'm currently waiting for codidact to get rolling, they're going to need awhile.
@IvenBach It's no surprise, but I did learn a lot more about not only async/await but also Task.Run(() => YourMethodHere) after I last talked to you, and feel confident that I have the basics down on when you should use async programming vs when you should delegate tasks to the thread pool, please feel free to hit me up about those topics if you ever get to use C# at work.
@BigBen As far as I can tell it's doing just fine, just takes a lot of effort to get things off the ground. I stopped following day to day progress a few weeks ago, but when I last checked they were working hard on user authentication. There's been a lot of unavoidable spinup work. It's different from a project like this that basically started as Mat and RD and grew from there. They had a ton of contributors from the start, so they needed to sort out things like conventions, and to ...
... have group conversations about what off the shelf pieces they'd be using to put it all together, etc.
@puzzlepiece87 I’ll never be using c# for work. They are adamant about staying with Excel/VBA. Will keep you in mind for RD use or if I get an offer from a new place.
VBA Rubberducking
VBA Rubberducking