TaloWeb

Oggi ho scoperto che le colonne con incremento automatico in SQL Server non sono così ingestibili come pensavo poco tempo fa… infatti si può sapere e modificare qual’è l’id successivo che verrà generato tramite comandi BCC:

Per sapere qual’è il “seed” della tabella:

DBCC checkident ('nome_tabella')

Per reimpostare il “seed” della tabella:

DBCC checkident ('testi', reseed)

Per reimpostare il “seed” della tabella ad un certo valore:

DBCC checkident ('testi', reseed, 144)

A volte, soprattutto in fase di testing delle applicazioni web è opportuno lanciare il browser ma in modo che il Javascript non sia abilitato. Con FireFox si può usare il famosissimo plugin No-Script, mentre per eseguire Chrome senza il Javascript abilitato su XP bisogna lanciare da riga di comando

"C:\Documents and Settings\[USERNAME]\Impostazioni locali\
Dati applicazioni\Google\Chrome\
Application\chrome.exe" -disable-javascript

dove “[USERNAME]” è il nome dell’utente che autenticato si sta usando.

Se dovete prendere un backup di un DB Sql server fatto da un hosting provider (per esempio usando “mylittlebackup” di Aruba) ed importarlo in un Db locale, troverete un problema: tutti gli oggetti avranno come schema l’utente del database invece che il più standard “dbo”.

Per risolvere, dopo aver importato il DB è necessario eseguire per tutti gli oggetti coinvolti uno script del genere

ALTER SCHEMA dbo TRANSFER Mssql12345.tablename

(dove ‘Mssql12345′ è il nome dell’utente del DB e ‘tablename’ il nome della tabella)

questo risulta noioso se gli oggetti sono tanti, la soluzione più semplice (che non coinvolga cursori e query complesse) è quella di eseguire una query del tipo

SELECT 'ALTER SCHEMA dbo TRANSFER Mssql12345.' + name
FROM sys.objects
WHERE type='U'

e di usare il risultato per eseguire la query di aggiornamento dello schema…

Se lavorate un po’ con WordPress potreste essere già incappati in questo errore, molto fastidioso e a volte di non immediata soluzione.

Sintomo: ad un certo punto viene mostrato un warning sulle pagine del sito che dice “WordPress Error – Headers Already Sent…” il file incriminato è spesso indicato nel messaggio di errore stesso.

Causa: cercando un po’ in giro si capisce subito che il problema è la presenza di spazi o righe vuote DOPO il codice di chiusura ?> in un file php (quello indicato nel messaggio di errore). A volte ma più raramente accade che il problema si uno  spazio presente PRIMA del codice di apertura <?php

Cura: sembrerebbe ovvio che cancellare le righe o gli spazi vuoti in questione dovrebbe risolvere il problema, se questo non funzionasse (per esempio perchè il server linux, il tipo di trasferimento ftp, l’editor di testo o la codifica ANSI/UTF8 aggiungono anche un solo byte) la soluzione è OMETTERE totalmente il tag di chiusura del php ?> pratica perfettamente valida che risolve definitivamente la questione.