I am making a website with a sign up function to sign up for specific classes and I need to create a persistent counter that shows how many spots are left for each class. Basically I need something that says, "if the sign up form has been submitted, find the specific class time and subtract 1 from that class's spots remaining int counter. I have a php validation form and can easily code this function but I don't know how to make the int-- change persistent. I have experimented with sessions, cookies, and mysql but none of them are really what I need. Surely there's a straight forward way to subtract 1 from an int var when the form is submitted without resetting the var. Any help is appreciated!
I dont understand what you want, but if you want just substruct 1,and at the same time have a limit in subtraction, Just create table or fields "maxcount" "nowcount". During registration just compare "nowcount" and "maxcount", if "nowcount" == "maxcount", then not substract.
1) Post your code.
2) hoping that your tables are related, i.e one table for number of courses, and another for userid and courseid many to many relationship.
You first store the set number of users in the course table that has the allowed register count. Then whenever a student submits a form, run a check to fetch the remaining count. From that, subtract 1, run an update query to change the value in the course table.
"SELECT total_seats_remaining FROM course WHERE courseid=xx"
Store result in new variable and subtract 1.
"UPDATE course SET total_seats_remaining = 'var' WHERE courseid = xx"
Related
I am creating a job number system that a few users will be using at the same time. I have created a job number on the php page and then it saves the number to the job sheet and uses this to link other tables to the job.
I take the job number from a table called numbers which then should increment the number by 1 each time the job is submitted ready to create the next job.
But the numbers are not working correctly.
As an example I get 1,2,3,4,8, then 43,44,45,then 105
I cant see why they would jump so much
$job_number_query = "SELECT * FROM numbers";
$job_result =($mysqli-> query($job_number_query)) ;
$job_num = mysqli_fetch_assoc($job_result);
$increment_job_number = $job_num[job_number];
$update_job_number_query = "UPDATE numbers SET job_number = $increment_job_number +1 ";
$mysqli-> query($update_job_number_query);
//echo ($customer_id);
Then I simply insert the $increment_job_number into the jobsheet table.
I am using int for the Job_number field in the table numbers
I cant think of a way to test the numbers. I guess a way is to look through the jobsheets and add another number to there but because more than one user might have a job that hasn't been submitted yet would this also cause problems.
Just increase the value without the first SELECT:
UPDATE numbers SET job_number = job_number +1
You have no where clause on your update query, so you're incrementing the job_number field in ALL records in the table.
It was me that was the technical failure in the end. I have got the incremental numbers on the create page but then unfortunately I had also got the incremental number on the edit pages so every time I edited the pages I then added 1 to the number field in the numbers table.
My situations is this... I have a table of opportunities that is sorted. We have a paid service that will allow people to view the opportunities on the website any time. However we want an unpaid view that will show a random %/# of opportunities, which will always be the same. The opportunities are sorted out by dates; e.g. they will expire and be removed from the list, and a new one should be on the free search. However the only problem is that they will always have to show the same opportunity. (For example, I can't just pick random rows because it will cycle through them if they keep refreshing, and likewise can't just take the ones about to expire or furthest form expiry because people still end up seeing the entire list.
My only solution thus far is to add an extra column to the table to mark that it is open display. Then to count them on display, and if we are missing rows then to randomly select a few more. Below is a mock up...
SELECT count(id) as total FROM opportunities WHERE display_status="open" LIMIT 1000;
...
while(total < requiredNumber) {
UPDATE opportunities SET display_status="open" WHERE display_status="private" ORDER BY random() LIMIT (required-total);
}
Can anyone think of a better way to solve this problem, preferably one that does not leave me adding another column to the table, and possible conflicts if many people load the page at a single time. One final note as well, it can't be a random set number of them (e.g. pick one, skip a few, take the next).
Any thought/comments would be very helpful,
Thanks.
One way to make sure that a user only sees the same set of random rows is to feed the random number generator a seed that is linked to that user (such as their user_id). That means every user gets a random ordering of rows but it's always the same random ordering for each user.
Your code would be something:
SELECT ...
FROM ...
WHERE ...
ORDER BY random(<user id>)
LIMIT <however many>
Note: as Twelfth pointed out, as new rows are created, they will get new order values and may end up in your random selection.
I'm the type that doesn't like to lose information...including what random rows someone got to see. However I do not like the modification of your existing table idea...
Create a second table as randon_rows or something to that extent to save the ID's of the user and the ID's of the random records they got to see. Inner join to the table whenever you need to find those same rows again. You can also put expirey dates and the sort in the table as well, so the user isn't perma stuck with the same 10 rows.
I'm creating a page that needs to select a Unique ID for every page load. It's basically a purchase order system, but the PO will be just the UID, so it's important that no user can get the same ID. I tried doing just calling upon last ID, then adding 1 and submitting, but that could create conflict if two or more users are entering at the same time. What's the best way to pull a UID for each page load? Any solutions?
Thanks
Lloyd
UniqId() is one way, but results in large numbers. As V Patel says, there's also "Auto Increment" and this is probably the option you want.
In MySQL set up a table (say "PurchaseOrders") with a field "po_id" and set that to be the primary key and auto increment. Add another field "po_status" (TinyInt*1) and another "po_lastused" (Date*1). Status will be 0=draft, 1=final, 2=shipped etc. LastUsed is the last time the user accessed the details.
When you want to create a new purchase order, INSERT INTO PurchaseOrders(po_status, po_lastused) VALUES(0, NOW()); Note: you've not specified the actual purchase order
You can get the po_id through asking for the "last insert id" (http://php.net/manual/en/mysqli.insert-id.php, http://php.net/manual/en/function.mysql-insert-id.php, http://www.php.net/manual/en/pdo.lastinsertid.php, depending on your coding library)
Store the po_id in a session variable so that when the user returns, you know their po_id(*2)
Each time a user access a purchase order, if "last updated" was more then 5 minutes ago, update the timer.
Periodically deleted all purchase orders that are draft and where last updated is older than your session (e.g. after a day)
This way, you'll end up with nice purchase order numbers that are easily quotable.
*1 For the purists, You can also use Enum for the status, and int for dates - depends on your preference. You can also set the date to be automatically updated. But I'm keeping it simple.)
*2 Again, for the purists, there is more security you could implement here to ensure the "other" users can't access someone else's purchase order, but this is enough to start.
You can use the uniqid function to get a unique key. Run it through hexdec if you need an integer.
PHP has one:
http://php.net/manual/en/function.uniqid.php
Use auto increment feature of the database in use, especially if you like it to be a number and don't need it till you want to persist it.
I am trying to develop an application where a guest user can see search results only 10 times after which he should be directed to payment page. I can use sessions on the search results page, but how can i put a counter on that. Can any please help me on that.
Every time a search request is created you just do
$_SESSION['counter']++
Altough he can just get rid of the limit by deleting cookies. An other approach would be, to store the number of search requests in a database table including the IP address, but this can also be bypassed, while it takes more work to do so.
If you should put search limit on current running session than you can use $_SESSION['count']++.
And if you should put search limit per day than you can use 'UPDATE users SET search_count = search_count+1'
It depends whether you would allow him to search again when he comes to your website or just those 10 times even after he visits after a year.
For temporary bases, you can use cookies (see setcookie function) but if you want to restrict him once and for all, you will have to ssave that information in database.
You would code something like:
<?php
session_start();
$_SESSION['counter'] += 1;
// more logic/code
Now you will have to save the value of $_SESSION['counter'].
If your users can search only while logged in, then I see no problem - you definitely have db table with users, so just add another column to it, say 'search_count' and increase it by one each time user attemps a search.
For example:
UPDATE `users` SET search_count = search_count+1
You can also use a counter in the table user of your db and call a function everytime the user looks for the result, that increments the value by one, so a simple UPDATE.
I think maintaining database will be much better then maintaining SESSION because may be due to some reason session removed or erased.
add a field within users table name for example visit with default value 0 and update this field on every visit of search result page..
"update usertablename set visitfield = visitfield + 1 where user_id = ".$current_user_id
thanks
I'm having some trouble approaching a +1/-1 voting system in PHP, it should vaguely resemble the SO voting system. On average, it will get about ~100 to ~1,000 votes per item, and will be viewed by many.
I don't know whether I should use:
A database table dedicated for voting, which has the userid and their vote... store their vote as a boolean, then calculate the "sum" of the votes in MySQL.
A text field in the "item" table, containing the uids that already voted (in a serialized array), and also a numeric field that contains the total sum of the votes.
A numeric field in the "item" table, that contains the total sum of the votes, then store whether or not the user voted in a text field (with a serialized array of the poll id).
Something completely different (please post some more ideas!)
I'd probably go with option 3 that you've got listed above. By putting the total number of votes as another column in the item table you can get the total number of votes for an item without doing any more sql queries.
If you need to store which user voted on which item I'd probably create another table with the fields of item, user and vote. item would be the itemID, user would be the userID, vote would contain + or - depending on whether it's an up or down vote.
I'm guessing you'll only need to access this table when a user is logged in to show them which items they've voted on.
I recommend storing the individual votes in one table.
In another table store the summary information like question/poll ID, tally
Do one insert in to the individual votes table.
For the summary table you can do this:
$votedUpOrDown = ($voted = 1) ? 1 : -1;
$query = 'UPDATE summary SET tally = tally + '.$votedUpOrDown.' WHERE pollid = '.$pollId;
I'd go with a slight variant of the first option:
A database table dedicated for voting, which has the userid and their vote... store their vote as a boolean, then calculate the "sum" of the votes in MySQL.
Replace the boolean with an integer: +1 for an up-vote and -1 for a down-vote.
Then, instead of computing the sum over and over again, keep a running total somewhere; every time there is an up-vote, add one to the total and subtract one every time there is a down-vote. You could do this with an insert-trigger in the database or you could send an extra UPDATE thing SET vote_total = vote_total + this_vote to the database when adding new votes.
You'd probably want a unique constraint on the thing/userid pair in the vote tracking table too.
Keeping track of individual votes makes it easy to keep people from voting twice. Keeping a running total makes displaying the total quick and easy (and presumably this will be the most common operation).
Adding a simple sanity checker that you can run to ensure that the totals match the votes would be a nice addition as well.
serialized array: Please don't do that, such things make it very difficult to root around the database by hand to check and fix things, serialized data structures also make it very difficult (impossible in some cases) to properly constrain your data with foreign keys, check constraints, unique constraints, and what have you. Storing serialized data structures in the database is usually a bad idea unless the database doesn't need to know anything about the data other than how to give it back to you. Packing an array into a text column is a recipe for broken and inconsistent data in your database: broken code is easy to fix, broken data is often forever.