SQL Triggers and Cursors - duck lips tucked in, we're using a cup today! All those learning to read SQL with Triggers and Cursors, what did you think about how you were going to explain these functions?
I look at this portion of SQL and consider never using it. However, the multiple que for every value within this itinerary is appeasing. I think of an actual programming skill, how to activate what you want and when it's going to happen in this fantastic attempt of learning how to put it so it works just as it is intended to be! There is no tone here, just factual delight that this has to come from another developer in the modularizing of SQL itself. Learning everything up to Views thus far and Stored Procedures into this section - I feel like the visualization and flow of what it is doing, is a borrowed system. It feels, temporary.
The Triggers are able to aim and pull an activation that sets off a series of events and possibly cursors (multi-dimensional arrays) of values to get the job done. The effect is simple. I understand it. However, the @@FETCH Status does not fit well with me, hence the name to retrieve as a unit together that arrives from something that should be separate one-at-a-time. It is hard to keep these functions separate, since they work together, but the connection that can be made using a regular JOIN statement should suffice this. Why use the @@FETCH command if it doesn't have its own story?
@@FETCH has a definition that sounded like a space tool that roves and collects like the trash collector repurposed essence in the form of a hired hand. This explained how it could loop throughout the code and bring forth its full bounty. The part that I want to know more about this is how does a @@FETCH Status resource the variable? Does that variable then become empty? Does it change? Is it labeled differently after, in programming? Using this style of looping in SQL does set it apart from other programming languages but I noticed the similarity between robotic programming as well. The SQL is interacting with binary commands that exchange a defined peice of space to explain how those variables were attained. This is attracting my vision of what SQL authors envisioned a database as and what they were doing to pick at specific components with a fine-tooth comb tool. It is simple and it creates the world of it as plausible as possible.
You know this can get more complex.