MySQL Mass edit vraagje 8)7

[Frustus Maximus]

Beste,

Ik heb een testsite bij byte.nl maar die is sinds kort live gegaan. Echter in mijn database staat nog heel vaak (3000+) keer het ouder byte.nl adres. Dus dit: mijnwebsite.nl.testbyte.nl/wp-admin/etc

Nu wil ik graag overal ".testbyte.nl/" vervangen voor "/"

Deze code heb ik gebruikt, maar dat werkt niet:

UPDATE leads
SET status = "/"
WHERE status = ".testbyte.nl/"

Deze foutmelding krijg ik:
#1146 - Table 'db_mywebsite9349.leads' doesn't exist

Weet iemand wat ik moet doen om deze code wel te laten werken?

Alvast bedankt,

Frustus Maximus

[ Voor 7% gewijzigd door Frustus Maximus op 12-05-2016 15:49 ]

[Afvalzak]

Heet je tabel wel leads of is het misschien met een hoofdletter?
Zit je wel in de goede database te werken als je deze query uitvoert?

Probeer eens

MySQL:

select * FROM leads;

werkt dat wel?

[ Voor 24% gewijzigd door Afvalzak op 12-05-2016 15:51 ]

[Fresh]

Aan de foutmelding te zien vermoed ik dat je de tabelnaam niet goed hebt geschreven.

Probeer anders even met SHOW TABLES je gewenste tabelnaam te checken.

EDIT:
Ik denk niet dat het om een bug gaat maar toch wel een noemenswaardig om hier neer te zetten.

Op stackoverflow had iemand ook een soortgelijk probleem:
http://stackoverflow.com/...le-xxx-xxxxx-doesnt-exist

[ Voor 43% gewijzigd door Fresh op 12-05-2016 15:58 ]

[RobIII]

Die update gaat sowieso nooit werken... Je where clause gaat niet matchen en als 'ie matched zet je de status op "/" ipv "/wp-admin/...". Dus wees maar blij dat er een fout in je tabelnaam zit (verkeerd default database geselecteerd vermoed ik?).

Je where zal een status like '%.testbyte.nl/%'-achtig iets moeten worden en je set zal een replace(`status`, '.testbyte.nl/', '/') moeten bevatten.

[ Voor 56% gewijzigd door RobIII op 12-05-2016 16:00 ]

[Rannasha]

RobIII schreef op donderdag 12 mei 2016 @ 15:56:
Die update gaat sowieso nooit werken... Je where clause gaat niet matchen en als 'ie matched zet je de status op "/" ipv "/wp-admin/..."

Dit dus.

Je zult de REPLACE functie moeten gebruiken om een deel van een tekenreeks te vervangen.

Maar dat is onafhankelijk van je huidige probleem waarin de tabel simpelweg niet gevonden wordt.

[ Voor 12% gewijzigd door Rannasha op 12-05-2016 16:00 ]

[Afvalzak]

RobIII schreef op donderdag 12 mei 2016 @ 15:56:
Die update gaat sowieso nooit werken... Je where clause gaat niet matchen en als 'ie matched zet je de status op "/" ipv "/wp-admin/...". Dus wees maar blij dat er een fout in je tabelnaam zit (verkeerd default database geselecteerd vermoed ik?).

Je where zal een like '%...%'-achtig iets moeten worden en je set zal een replace(...) moeten bevatten.

Als je REPLACE gebruikt hoef je in dit geval ook die like niet meer te gebruiken.
Is wel veiliger natuurlijker.

code:

UPDATE leads SET url = REPLACE(url, '.testbyte.nl/', '/')

[Frustus Maximus]

Bedankt voor de snelle reacties
Ik probeer nu om iedere tabel apart te nemen:

UPDATE wp_options
SET status = '/'
WHERE status = '%.testbyte.nl/%'

Maar dan zegt hij:
#1054 - Unknown column 'status' in 'where clause'

Dit heb ik ook geprobeerd:
UPDATE wp_options SET url = REPLACE(url, '.testbyte.nl/', '/')

Maar dan krijg ik ook een foutmelding: #1054 - Unknown column 'url' in 'field list'

[ Voor 28% gewijzigd door Frustus Maximus op 12-05-2016 16:07 ]

[kenneth]

Frustus Maximus schreef op donderdag 12 mei 2016 @ 16:05:
Maar dan krijg ik ook een foutmelding: #1054 - Unknown column 'url' in 'field list'

Wat denk je dat die foutmelding betekent?

[Frustus Maximus]

UPDATE wp_options
REPLACE status = "/"
WHERE status like = "%.testbyte.nl/%"

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'REPLACE status = "/" WHERE status like = "%.testbyte.nl/%"' at line 2

[Afvalzak]

Mag ik je de tip geven om gewoon dit artikel te volgen:
https://codex.wordpress.o...Your_Domain_Name_and_URLs

En dan met name deze tool:
https://interconnectit.co...-for-wordpress-databases/

[ Voor 28% gewijzigd door Afvalzak op 12-05-2016 16:12 ]

[NMe]

Sorry, maar ga gewoon even begrijpend lezen. Je dumpt hier foutmelding na superduidelijke foutmelding. Dat een kolom niet bestaat lijkt me een heel goed te begrijpen melding waar je prima ook zelf op kan acteren. Hetzelfde geldt voor die syntaxfout in je laatste post. RobIII en Afvalzak noemen hierboven nota bene precies het commando dat je moet gebruiken en nog gebruik je niet de stringfunctie maar het commando REPLACE dat iets heel anders doet.

Hou even op met gewoon maar wat doen. Hou even op met domweg elke foutmelding hier dumpen. Ga voor de grap eens lezen hoe je de functionaliteit die je nodig hebt moet gebruiken in plaats van je livedatabase potentieel om zeep te helpen omdat je blind willekeurige commando's uitvoert.

[Creepy]

Sorry, maar dit soort foutmeldingen mag je toch eerst zelf proberen op te lossen i.p.v. hier direct te dumpen zonder verder te laten zien wat je nu zelf hebt gedaan. We zijn hier geen persoonlijke helpdesk.

"Unknown column..." betekent letterlijk dat, URL is blijkbaar geen kolom in je tabel. En dubbelcheck ook je laatste query, want "status like = ..." daar klopt echt helemaal niks van. Hoe een UPDATE werkt in MySQL is gelukkig goed bechreven in de online handleiding en met google snel te vinden

_{* Creepy mept NMe.....}

[ Voor 4% gewijzigd door Creepy op 12-05-2016 16:18 ]

[RobIII]

Afvalzak schreef op donderdag 12 mei 2016 @ 16:01:
Als je REPLACE gebruikt hoef je in dit geval ook die like niet meer te gebruiken.

Euh, nou ja, het is-en-blijft MySQL en die zal anders voor élk record (AFAIK) de replace invoken (die dan weer een ongewijzigd result geeft weliswaar), maar die 'bespaar' je jezelf natuurlijk als je dat alleen maar doet op records waar die tekst überhaupt in voor komt. Als maar 1% van de records in een tabel met miljoenen records die tekst bevat scheelt dat 999.000 invokes van de REPLACE functie die vervolgens (weer) op zoek gaat naar een match in de tekst om er dan achter te komen dat er niets te vervangen is.

Having said that; het gaat hier zeer waarschijnlijk maar om een paar recordjes, de like %...% levert je toch al een full table scan op etc. etc. dus uiteindelijk kun je inderdaad de where wel achterwege laten in dit geval. Ik vind 't echter een goed gebruik / je aan te leren/wennen dat een where-clause, in principe (uitzonderingen daargelaten), aanwezig hoort te zijn in een update/delete.