Jump to content

Jim R

  • Posts

  • Joined

  • Last visited

  • Days Won


Jim R last won the day on July 26 2018

Jim R had the most liked content!

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Jim R's Achievements

Prolific Member

Prolific Member (5/5)




Community Answers

  1. So just unique keys set up in the schema? I though you meant all the selected fields: schoolid , nameFirst , nameLast , feet , inches , grade , position Your answer was way more succinct than what the manual provided. Trust me, you can ignore most coaching books.
  2. It's really just a yes or no question, but ok. Let's pretend I understand all of it. That means it has to trigger a unique or duplicate key, and I don't want that in a general way for the reasons I cited above.
  3. That didn't answer my questions, nor address my concerns over it. If I could derive understanding from what I had already read, I wouldn't ask questions. So either i'm misunderstanding its application, or it's not working for my needs. It would be like if I handed you a book of how to coach basketball and sat back watched you try to do that. Do they only ignore the entries that match the presented fields entirely?
  4. Another issue with INSERT IGNORE is it has never worked for me. $stmt2 = $con->prepare("INSERT IGNORE INTO wp_terms(name, slug) VALUES (?,?)"); $stmt2->bind_param('ss', $name, $slug); We also had that earlier in this discussion -- adding WordPress slugs. Each time I test out entering Jon Doe into a_players and a_rosters, it's added a new row in wp_terms with the same values.
  5. I do appreciate your time. 1) There is a decent amount of code amid the INSERT IGNORE you had not presented yet, which likely answers the question I asked before of how does it account for the arrays. I don't believe you answered that, and toward that I wasn't sure where to apply that code. I'm presuming, "holders" and "array_push" answer that question. 2) I have no doubt my code is often sloppy and piecemeal. 3) How do the INSERT IGNOREs operate? Do they only ignore the entries that match the presented fields entirely? If so, I don't think that will work for a few reasons: On a_players, the heights could and often do change from season to season. Any change in height would cause the insertion of the same player. On a_rosters, there will be duplicate players entered, once for each season they're on varsity. I have a DUPLICATE KEY set up to check for schoolID, playerID and season. I would like cleaner code. I'll have a chance to dig into this later today. Thanks.
  6. Not even remotely out of laziness. The query just gets written once, whether I have to join it or not. It's already written. The viewing of data will be utilized far more times than the inserting of it. It gets inserted/updated once a year, vs. viewed dozens to hundreds of times a day. It certainly has nothing to do with the issue at hand.
  7. 1) They will be the same, but there are times when I will call the list of players from a_players. It seems easier to have their varsity status in that table than having to join a_rosters just to get it. (Duplicate key update to handle that as kids get older.) 2) There will not be players from different schools playing on a school's team, just players from that school.
  8. team = schoolID I've made all the changes accordingly, and that's not been a problem at all. I have varsity in both tables because there will be times I call on a_players and only needing their varsity status off of a_rosters. a_players a_rosters However, hold for a minute. I tested it out with multiple players, and it didn't really work. As best as I can tell it produced the following: in a_players: player 1: id, fname, name, feet, inches, schoolID, grade, varsity player 2: nothing in a_rosters: player 1: nothing player 2: schoolID, uniform, player ID of player 1, varsity, season WTF?
  9. I echoed out what you suggested above: $pid->execute(); $pid->bind_result($playerID); $row = $pid->fetch(); echo 'playerID: ' . $playerID .' value of row: '. $row;
  10. What's $row producing in what you typed? Why wouldn't that be a variable being passed to the next query? Not fully sure how it works, but if we're binding a result to $playerID, shouldn't that value be passed to the next query?
  11. That yielded what I had earlier, at least visually. It produced the row in a_players (table). It echoed the newly created id, but it did not produce an id in a_rosters. That version didn't even produce a new row in a_rosters. What I had was doing that, just without passing the $ playerID.
  12. Line 95 ==> $row = $pid->fetch_assoc(); I have an echo in there too, so I know it's finding the id. It's not pushing to the $roster query.
  13. I should say it worked enough to get and print the id in question and didn't throw an error.
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.