I have been using a query to add editable profiles based on an original user table.
The original registration table has the fields, id - name - surname - username - password - email - confirmation
The profile has several more customizable fields, but the ones I am inserting into the profiles table from the users table is, id - name - email.
INSERT IGNORE INTO profile(cid,display_name,display_email)
SELECT id,name,email FROM users
This used to work for a couple of years now, but recently I noticed that the profiles table has topped inserting profiles when users register. When I run the query in phpmyadmin it just says 0 rows inserted.
Can someone please help me to figure out why this is happening? Updates to MySQL that I missed or something :(
Solved the problem.
It would seem my host for some reason, during upgrades changed my table field id on the profiles table to a defined value of 0.
I edited the structured and set it back to auto_increment. Which was the reason the query stopped adding the new values.
Thank you to everyone that questioned me, it pointed me towards the problem and helped to resolve this issue.
Related
I am doing some Bluetooth project where I have a device sniffing for MAC addresses. I want those sniffed addresses to be saved to a certain table (In my case called "Visitors").
Now, the thing is. The tables I_year_student and II_year_student will have a manually inserted records. I want all found devices to be saved to the Table "Visitors". The problem is: sometimes one MAC address which is already in the table I_year_student is going to be sniffed by the device again, and of course, it is going to be saved to the database again, more precisely, to the table "Visitors". Now I have two identical records in two different tables and I don't want that to happen.
Is there a way, where after my device finds a certain MAC address, to check if the record already exists in other tables. Something like this:
I found a "new" MAC address
Before inserting that record to the table "Visitors" check if there is a similar record in other tables in the database.
If there is a similar record ignore it.
If the record is unique save it to the table "Visitors"
A part of the code for sniffing and inputing to the table Visitors is written below:
if len(nearby_devices) > 0:
print(len(nearby_devices))
for addr, name in nearby_devices:
try:
cur.execute("""INSERT INTO Visitors
(Address, Name)
VALUES
(%s,%s)
""", (addr, name)
)
con.commit()
OK, thanks everyone for help but I think I found and answer and manage to solve the problem:
My situation was this. I have a device that is always sniffing for MAC addresses on Bluetooth protocol and I wanted to save all the addresses that I've found to MySQL database for later processing. Also, I wanted to save those addresses by separating them based on different profiles, for example:
mac_address1 : Column: ProfileID (typeA)
mac_address2 : Column: ProfileID (typeB)
mac_address3 : Column: ProfileID (typeC), and so on...
The thing is that my database already has some manually added mac addresses and I didn't want my new addresses (that could also be old, because some devices can enter the sniffing area again) to be saved again under some ProfileID, while I already have them under some other ProfileID.
So, after some thinking I wrote the query and tested it and now it's working fine.
cur.execute("""INSERT INTO ordenador
(Address, Name, ProfileID)
VALUES
(%s,%s,'public')
ON DUPLICATE KEY UPDATE
ProfileID = VALUES(ProfileID)
""", (addr, name)
)
Now, when my device catches a "new" mac address, he inputs that record to the table "ordenador" and if the record for "new" mac address already exists there, it just update the record to the old one. In other case, if the record doesn't exist there, the query inputs the record under a ProfileID, in my case "public".
All the suggestions and thoughts are welcomed. I hope this will help to someone who already had some similar issues.
I have an unusual problem.
When I create a new user in the Wordpress back-end, it appears the _usermeta info isn't being created in the database.
Usually what would happen is a row gets added to the _users table (containing ID, email, password etc...) and a bunch of rows with the corresponding ID get added into the _usermeta table (containing their name, capabilities etc...).
But as mentioned the rows for the _usermeta are not being created.
Some other facts:
a new row for the user does get created in the _users table for the user, but it doesn't appear to be taking the next available ID after the latest. For example, if the latest ID in that table was 1200, then the next user added should be 1201. But it's instead adding the row earlier in the table.
this database was exported from the site when it was on my previous host (a couple of days ago), where it used to work fine. I'm guessing something happened during the dump?
Some things I have tried to fix it:
Disabling all plugins.
Different theme (no functions)
Wordpress database repair
Any help would be appreciated.
Solved. For some reason auto increment had disappeared from the structure. I added it and now it's all fine.
Though is anyone can explain, how could this go missing during the database dump?
I'm using some code written for once place in another, which I guess is the start of my problems.
In my ideally unchangeable existing code I have a query something like:
SELECT username FROM users
However, in the new database, there is no username field, but there is an email address.
I'd like to change the new database somehow so that when I ask for username I get back the email.
I understand that I can just make a new field and manually populate it when the email updates, but I'd really like some kind of alias so that both codebases can work without modification.
Is this possible?
You could create a view:
CREATE VIEW v_users AS
SELECT email AS username
FROM users
Since this is over just one table, you could even use it for updates and inserts as well as queries (if you are using a relatively new version of MySQL)
You could even create all the views in a separate database - that way they could have the same names as the original tables:
CREATE VIEW db2.users AS
SELECT email AS username
FROM db1.users
You could add the username field and keep it aligned to the e-mail address through a trigger, or you could use a view of the users table.
Triggers: http://dev.mysql.com/doc/refman/5.5/en/create-trigger.html
Views: http://dev.mysql.com/doc/refman/5.5/en/create-view.html
Unfortunately, MySQL does not support Computed Columns.
There are a few workarounds from what I found when googling this matter, but you're probably best off just copying the values, or using a trigger which automatically updates it.
I'm working on a RoR projects. I'm migrating a user table. Because the new dbase has a different set up and I want to seperate the login stuff from the personal/settings stuff I'm not importing the dbase; I migrate all attribute separately. I want to keep the old user id's. When I use user=User.new I can do user.id = migratee.user_id and I keep the same user_id. Unfortunately in the old table different users where registered with the same email address (don't ask why). Off course I don't want that so what I do in stead of user=User.new is user=User.find_or_create_by_email(migratee.email). This is going to lead to some problems, I know, since users with same email address will be overwritten. This is a problem I 'll deal with seperately. My problem is that when I do user.id = migratee.user_id after user=User.find_or_create_by_email(migratee.email) the old ID isn't migrated but a new auto-incrementing id is assigned. Anybody know how to avoid that?
Regards,
Rutger
I don't know how your query looks like. If you're doing an INSERT SELECT you can add a HAVING to filter existing email adresses. Otherwise you could do a GROUP BY email do only get one email.
If its a once off I would probably just turn off the auto_increment in your new mysql table id column until you have finished your migrations and then turn it back on or/ create another column called udid in the new database table (and then rename and delete the id col). Probably nicer ways to do it, but its fast and easy.
i am scrubbing my head now for hours to solve thw following situation:
Several Html Forms on a webpage are identified by an id. Users can create forms on the clients side themselves and fill in data. How can I guarantee that the id of the form the user generates is unique and that there doesnt occure any collision in the saving process because the same id was generated by the client of someone else.
The problems/questions:
A random function on the client side could return identical id's on two clients
Looking up the SQL table for free id wouldnt solve the problem
Autoincrement a new id would complicate the whole process because DOM id and SQL id differ so we come to the next point:
A "left join" to combine dom_id and user_id to identify the forms in the database looks like a performance killer because i expect these tables will be huge
The question (formed as simple as i can):
Is there a way that the client can create/fetch a unique id which will be later used as the primary key for a database entry without any collisions? Whats the best practice?
My current solution (bad):
No unique id's at all to identify the forms. Always a combination through a left join to identify the forms generated by the specific user. But what happens if the user says: Delete my account (and my user_id) but leave the data on the server. I would loose the user id and this query qouldn't work anymore...
I am really sorry that i couldn't explain it in another way. But i hope someone understood what i am faced with and could give me at least a hint
THANK YOU VERY MUCH!
GUIDs (Globally Unique IDentifiers) might help. See http://en.wikipedia.org/wiki/GUID
For each form the client could generate a new GUID. Theoretically it should be unique.
I just don't show IDs to the user until they've submitted something, at which point they get to see the generated auto-increment id. It keeps things simple. If you however really need it, you could use a sequence table, but it has some caveats which make me advise against it:
CREATE TABLE sequence (id integer default 0, sequencename varchar(32));
Incrementing:
UPDATE sequence
SET id = #generated := id + 1
WHERE sequencename = 'yoursequencename';
Getting:
SELECT #generated;