Service Pack 3 pentru SQL Server 2005 va apare până la sfârşitul anului 2008. Până atunci, poţi încerca ultimul Cummulative Update (momentan CU 10, KB 956854).Răzvan

Bogdan, cum să fie inutil ORDER BY-ul dacă există TOP 1 ? ORDER BY-ul este pus acolo tocmai pentru că există TOP 1, adică să specifice că e vorba de primul dintr-un anumit punct de vedere, nu un rând oarecare.Din alt punct de vedere, ai dreptate cu GETDATE()-ul din funcţii... se pare că sunt cam prea obişnuit cu limitările lui SQL Server ...

Pentru răspunsul la întrebarea ''Cum aş putea să folosesc datele returnate de o procedură?'', vezi următorul articol:http://www.sommarskog.se/share_data.htmlÎn acest caz, este posibil să foloseşti INSERT-EXEC, dar cel mai simplu ar fi să o faci funcţie, astfel:CREATE FUNCTION uspGetLastIdOfAddedArticle(@ParentId INT, @CurrentDate DATETIME)  ...

A apărut Cummulative Update 1 pentru SQL Server 2008. Vezi şi:http://sqlblog.com/blogs/aaron_bertrand/archive/2008/09/23/sql-server-2008-cumulative-update-1-is-available.aspxRăzvan

CREATE FUNCTION ZilelePrecedente(@Data datetime)RETURNS TABLE AS RETURNSELECT @Data-CASE (DATEPART(weekday,@Data)+@@DATEFIRST)%7        WHEN 0 THEN null        WHEN 1 THEN null        WHEN 2 THEN 3        WHEN 3 THEN ...

Se poate face, dar eşti sigur că nu trebuie să ţii cont şi de sărbătorile legale ?Răzvan

liviu.costea:[...] prefera sa citeasca zeci de mii de linii decat sa faca doua I/O la intamplare (asta de exemplu daca dau id-urile 1 si 30.000). [...] Dacă ar exista indecşi, nu mai face table scan şi hash join, ci ar face index seek şi nested loops, deci ar citi doar rândurile relevante.Dacă nu există indecşi, oricum citirea a două rânduri ...

Presupun că foloseşti SQL Server 2005. Aşa cum spunea şi Bogdan, SQL Server 2000 nu pune niciun filtru la table scan-ul pe tabela B. În schimb, SQL Server 2005, face o optimizare punând un filtru şi pe tabela B (mai precis ''ID_A >=1 AND ID_A <=3''). În condiţiile date (adică fără niciun index), mi se pare o optimizare inteligentă şi utilă. ...

Dacă nu faci backup-uri de log, trecerea înapoi pe recovery model-ul FULL este inutilă. Ar fi mai uşor să îl treci pe recovery model-ul SIMPLE şi apoi să-l laşi aşa (astfel nu o să mai ai probleme cu creşterea fişierului de log). Bineînţeles, asta înseamnă că renunţi la posibilitatea de a face point-in-time restore, dar dacă nu făceai backup-uri ...

Eu nu recomand BACKUP WITH NO_LOG (sau TRUNCATE_ONLY) nici în versiunile anterioare. Dacă e vorba de o bază de date de test, recomand recovery model-ul SIMPLE. Dacă e vorba de o bază de date de producţie, recomand backup-uri de log periodice. Dacă se doreşte totuşi să se facă ceva echivalent cu BACKUP WITH NO_LOG pe SQL Server 2008, atunci se ...