Jump to content

Phi11W

Members
  • Content count

    17
  • Joined

  • Last visited

  • Days Won

    1

Phi11W last won the day on March 7

Phi11W had the most liked content!

Community Reputation

1 Neutral

About Phi11W

  • Rank
    Member
  1. Phi11W

    rearrange dates in a DB table

    It's unclear (to me) what you want. To me, "uniform" generally means "the same", not "... 1 or 2 or 3 or 0 ...". If you want a pre-defined set of data, then delete the rows and reinsert them the way you want them. Also; you say "gap". Remember that rows in a relational table have no intrinsic order. Regards, Phill W.
  2. Phi11W

    Manipulate a single value in an array

    In a simple Array, each element can be indexed by its [numeric] offset. Note that's "offset", not "position"; we count from [offset] zero. Refer to http://php.net/manual/en/language.types.array.php Regards, Phill W.
  3. You can [manually] use "select *" for testing and diagnostics. Applications should never do so. Databases are intrinsically shared entities and other people might be changing the table structures, adding all sorts of gigantic "text" fields that your application doesn't [know or] care about but using "select *" will retrieve them all anyway. Regards, Phill W.
  4. Phi11W

    Call variable from another function in class

    You can't. When you create an instance of a class, it's constructor function gets run. Then and there. Your [calling] code waits until that constructor completes before carrying on. By the time your code gets around to calling the updateDB function, the code execution and, more importantly, the local variables within the constructor are long gone, so there are no local variables for you to access! Now, the number of accounts could be a class-level variable, because it persists after the constructor has run, but any idea of the "current" account? Probably not. Regards, Phill W.
  5. Phi11W

    Round number based on the magnitude of that number

    I fail to see the difference between the two cases. If the deciding factor is whether the magnitude of the value is greater than [or equal to] one, then CASE operator in the SQL should suffice. select case when abs( value ) >= 1 then round( value, 4 ) else value end value from ... Regards, Phill W.
  6. Phi11W

    PHP arrays and lists, assignmenthelp

    You could do worse than start by reading some bits of the Manual: Arrays: array Looping: for or foreach Conditions: if Regards, Phill W.
  7. Phi11W

    php sql syntax error

    $sql = "UPDATE ".$d203." SET u102='".$newPassword."', u103='N' WHERE 104=".$a104; Never use any value supplied by a user without validating it thoroughly first. Obligatory XKCD Reference: Little Bobby Tables. Never, ever store passwords in plain text. Generate a hash of the the user-supplied password and store/ compare against that. You appear to be using multiple tables (with the same structure) for multiple "things" (User groups?). That's generally a poor design choice and doesn't scale out half as well as you might think. Better to use a single table and to use other methods (views/ application code) to keep different "communities" separate from one another. You appear to be using arbitrarily-generated table and column names. This is also, generally, a poor design choice, unless you have a lot of metadata elsewhere in your database/application that describes what all of these meaningless names ("u102", "u103", etc.) actually mean. I would expect you to have a "Users" table containing columns like "ID", "Name" and "PasswordHash". If you're especially paranoid about values "bleeding" between user groups, then separate each into its own database. The SQL that you are building is a String values that just happens to be meaningful to your database engine. Always give yourself the opportunity to examine generated SQL before it gets submitted to the database. During development, take the generated SQL, copy and paste it into your database tool of choice and make sure that it works. As mac_gyver has already said, your WHERE clause ( "104=something" is never going to match anything (except the value 104, of course), so no rows will get updated. Regards, Phill W.
  8. You should be able to trust the data in your database. If that's wrong, then you're in a very Bad Place. You should try to protect "your" data at all times and that means checking, validating and, where necessary, encoding data on its way in; thereafter, it can be trusted. It's one of the oldest computing adages there is - "Garbage In; garbage out". These checks will not protect your site. All they will accomplish is to crash your web site after an attack has happened. If the data's been compromised, your checks will fail and nobody will get to see anything (except error messages) ... and the phones on the Help Desk will start ringing off the hook. Regards, Phill W.
  9. Phi11W

    Hi read encrypted password help.

    Along with the many other, worthy comments you've already received ... Don't read the encrypted value back at all! Add a condition to the "where" clause checking that the entered (and salted and encrypted) password matches the value in the user record. select ... from ... where username = ? and enc_password = ? If you don't get a record back, you don't let the user in (and you don't care why - you don't tell the hacker at your door that they've found a valid username and now only have to break the password!) Regards, Phill W.
  10. Your SQL is wrong: SELECT * FROM dow_list_01, dow_settings, dow_page_content ORDER BY dow_list_sort_order Your select statement mentions three tables but gives your database engine no clue how to "join" them together sensibly. Faced with such a request, your database will dutifully (and stupidly) join each and every record in the first table to each and every record in the second table (and then to each and every record in the third table!). It's known as a Cartesian (or Cross) Join and, in all but a tiny handful of cases, it is a [Performance-Crucifying], Data-Duplicating mistake. Also relevant, but far less important in this instance; avoid using "select * from ...". Databases are inherently a shared resource and if, in a few years time, somebody [else] were to add a hundred really, really big text fields to this table, you'd suddenly find your application running really, really slowly, as all that data - that your page doesn't actually [know or] care about - comes out of the database and chugs its way across the network. Regards, Phill W.
  11. Phi11W

    auto html comments

    And what purpose are these "comments" going to fulfil? Presumably, you'll be adding the same thing to each and every one, which begs the question - what's so important that it has to be in every file? Boiler plate comment blocks are probably of very little practical value or, indeed, downright "harmful" (see: https://dzone.com/articles/meaningless-docblocks). Regards, Phill W.
  12. > "The code is from a third-party site which I wish to get certain content from." Screen-scraping from other web sites is generally a Bad Idea. "I know Engineers, they love to change things!" You can build a carefully crafted script that works today and then, in a couple of weeks time and for no apparent reason, it suddenly stops working and you have to drop everything, chase around and rewrite your script to work with their new web page design. Sure it's "fun" the first couple of times you have to do this, but it gets "old" really quickly. You should be using a more stable, published API to get any data you require. Regards, Phill W.
  13. (1) Don't have your connect to your database as root. Create a dedicated account to be used by your application with the permissions that it needs to do its job. Only you get to use root, usually to clean up the mess made by applications or other people. (2) Never store passwords in a recoverable form (i.e plain text). Hash the password and store that result. When the user logs in, hash whatever password they enter and compare that with what's in the table. Regards, Phill W.
  14. Phi11W

    Php forms

    If I understand you correctly ... "Locking" the user into an invalid field gives a terrible User Experience, especially when you start having multiple fields that are validated with respect to one another. For example, given Start and End Dates, the user might enter the Start Date incorrectly but then gets "locked" into the End Date field because that is invalid with respect to the Start Date. Instead, validate all the fields, return/ display all the errors, then let the user sort out their own mess. Only once everything is valid do you allow the submit to continue. Regards, Phill W.
×

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.