Jump to content

enveetee

Members
  • Posts

    32
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by enveetee

  1. Thanks for the reply, which raises another question: If I use a Blowfish replacement (5.4) and PHP is updated to 5.5, will the Blowfish function be compatible with the replacement you suggest?
  2. <Newbie>My learning curve is almost vertical at the moment</Newbie> Over the last few months I have started migrating my VB application. Development has been on a PHP 5.5.16 system I have signed up to a hosting company which supports PHP 5.4.34 and my system does not work. Much digging and learning I discovered the password_hash function (using PASSWORD_BCRYPT) is causing the issue on the hosted 5.4 system So question is this. I would like to continue with 5.5 but I need to know what features/functions are not in 5.4 (is there a list) and is there a list of workarounds to help me implement 5.5 functionality in a 5.4 install Thanks
  3. @Jacques1 - many thanks for your answer, brilliant. I have another (well 1000's actually) question if you have time. My app (PHP/MYSQL) needs credentials to connect to MYSQL database. Where/how do I store those to ensure they are secure? Currently I have a file in a ../includes directory called connect.php, it contains my connection details. Is this safe, I am lead to believe that without access to the server these files are never 'served up' only executed. Thanks in advance
  4. @Jacques1 - thanks for that, it has put my mind at rest but has now got me thinking... How do you stop a user from changing a record which is already in use/being edited? In my desktop application, I applied a 'lock flag' to the record by locking the table/checking if the record has a lock flag and if it does not, apply a lock flag then return the record to the user. Any other user will see the lock flag and be unable to write to the record Is this how it works in MySQL? Thanks
  5. @Jacques1 - thanks for the reply. Currently my app is a desktop application written in a number of BASIC languages ranging from BBC Basic up to VB.NET, it's very old legacy code in it. My tables are flat text files modified by random access (not important). To prevent concurrent write access, I open the file for WRITING and lock it so no other process has access - do my INSERT or REPLACE the close the file. This is all done quickly and as efficiently as possible, no file is ever left open thus locking the entire system. If a file is already open, the next process waits, for 500ms or so for the current process to complete, then it tries again. Works well for users up to 10 or so As I am new to PHP/MYSQL, I am currently bringing my desktop mindset to this new development world, thus the question: Connect-Update/Replace-Disconnect - do I have to worry about locking. Your answer about atomic seems to help me a great deal. I know transactions across mulitple tables is a different matter but I am not there yet! Thanks Nigel
  6. Hi I come from a desktop (vb.net) background and have used oridinary text files for my databases. I use file locking to prevent other processes from writing to the same file simultaneously. Now I am moving over the PHP/MySQL - what precautions should I take to stop a simultaneous processes from writing to a table at the same time.? Do I need to lock the table before writing to it? Does MySQL deal with this automatically and just block my process until the table becomes free? (I am talking about a single table here, not multiple dependant tables - I know that is another issue) Thanks Nigel
  7. Hi there I am just finalising my first ever PHP/MYSQL project and I am worried about where to safely keep my connection credentials for the SQL DB. Currently, I am storing them in ../php/config.php and this works fine, but I am worried as to the security of this Can anyone advise please Thanks
  8. Hi Old guy getting into PHP/MYSQL from AMI Basic/Dragon Basic/BBC basic/QBX/PDS/VB/VB.NET - please be gentle!
×
×
  • 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.