jothaz

Fiz algo parecido que funcionava assim: Na minha tabela tb_ocorrencias criei um trigger que toda vez a que incluisse um registro gerava um registro em um tabela tb_emails. Dai cirei um aplicação vb que fica rodando como serviço no server e cada novo registro na tabel a e-mail envia amensagem para o destinatario e marca um flag no registro como enviado. Sei que é possivel enviar e-mails diretamente do SQL server mas acho que no seu caso só mesmo aplicação extern.

Pois é bareta achei a modelgem estranha.

Use DATEADD tanto na query de inclusão quanto no ASP: select getdate() as 'Data Atual', DATEADD(year, 10, getdate()) as 'Data Atual + 10 anos' Asp <% sSQL = "insert into sua_tabela (Data_de_Vencimento,.... outro campos....) values (DATEADD(year, 10, " & sua variavel & "),.... outro campos...." %>

Isso pode ser feito através de FRAME. Dê um pesquisa que achará vários exemplos.

você chegou a ver este exemplo?

Exemplo 01 DECLARE @TMP TABLE (NU_DOC INT, IC_ACEITO CHAR(1)) INSERT INTO @TMP (NU_DOC, IC_ACEITO, VALOR) VALUES (1,'A') INSERT INTO @TMP (NU_DOC, IC_ACEITO, VALOR) VALUES (2,'C') INSERT INTO @TMP (NU_DOC, IC_ACEITO, VALOR) VALUES (3,'') SELECT NU_DOC, IC_ACEITO, CASE rtrim(ltrim(IC_ACEITO)) WHEN 'A' THEN 'Aceito' WHEN 'C' THEN 'Cancelado' ELSE 'Não avaliado' END FROM @TMP Exemplo 02 DECLARE @TAB TABLE (CODIGO VARCHAR(10), MES VARCHAR(10) , VALOR DECIMAL(12,2)) INSERT INTO @TAB (CODIGO, MES , VALOR ) VALUES ('0101', '012003', 415235.25) INSERT INTO @TAB (CODIGO, MES , VALOR ) VALUES ('0101', '022003', 15235.45) INSERT INTO @TAB (CODIGO, MES , VALOR ) VALUES ('0101', '032003', 41535.78) INSERT INTO @TAB (CODIGO, MES , VALOR ) VALUES ('0101', '042003', 41523.20) INSERT INTO @TAB (CODIGO, MES , VALOR ) VALUES ('0201', '012003', 8564.25) INSERT INTO @TAB (CODIGO, MES , VALOR ) VALUES ('0201', '022003', 758.45) INSERT INTO @TAB (CODIGO, MES , VALOR ) VALUES ('0201', '032003', 35.78) INSERT INTO @TAB (CODIGO, MES , VALOR ) VALUES ('0201', '042003', 23.20) SELECT * FROM @TAB SELECT CODIGO, SUM(CASE SUBSTRING(MES,1,2) WHEN '01' THEN VALOR ELSE 0 END) AS DIA1, SUM(CASE SUBSTRING(MES,1,2) WHEN '02' THEN VALOR ELSE 0 END) AS DIA2, SUM(CASE SUBSTRING(MES,1,2) WHEN '03' THEN VALOR ELSE 0 END) AS DIA3, SUM(CASE SUBSTRING(MES,1,2) WHEN '04' THEN VALOR ELSE 0 END) AS DIA4 FROM @TAB GROUP BY CODIGO SELECT P1.*, (P1.DIA1 + P1.DIA2 + P1.DIA3 + P1.DIA4) AS TOTAL_ANO FROM (SELECT CODIGO, SUM(CASE SUBSTRING(MES,1,2) WHEN '01' THEN VALOR ELSE 0 END) AS DIA1, SUM(CASE SUBSTRING(MES,1,2) WHEN '02' THEN VALOR ELSE 0 END) AS DIA2, SUM(CASE SUBSTRING(MES,1,2) WHEN '03' THEN VALOR ELSE 0 END) AS DIA3, SUM(CASE SUBSTRING(MES,1,2) WHEN '04' THEN VALOR ELSE 0 END) AS DIA4 FROM @TAB P GROUP BY CODIGO) AS P1 Considerações finais: Esta é somente um das formas de como o CASE pode ser utilizado. No exemplo 02 mostra como simular uma consulta referência cruzada através de SQL puro (sei que não muita vantagem com as ferramentas de DW, mas fazer-se-a o que? :o ) inspirado no Books Online Irei acrescentando outros exemplos com o tempo. E lembrem-se estes exemplos não passam de elocubrações. Fonte/Autor/link AUTOR: "Jothaz" Dúvidas, criticas, contribuições, correções e adições serão bem vindas.

O fragmento a seguir mostra uma forma de como através de um CURSOR escrever por extenso um intervalo entre datas. Script: DECLARE @TAB TABLE (DATAI DATETIME, DATAF DATETIME, INTERVALO_DATA_EXTENSO VARCHAR(100)) INSERT INTO @TAB (DATAI, DATAF) VALUES ('2003/07/05 10:00','2003/08/07 15:30') INSERT INTO @TAB (DATAI, DATAF) VALUES ('2003/07/05 10:00','2003/09/07 15:30') INSERT INTO @TAB (DATAI, DATAF) VALUES ('2003/07/05 10:00','2003/09/07 16:00') INSERT INTO @TAB (DATAI, DATAF) VALUES ('2003/07/05 10:00','2004/09/07 16:00') DECLARE @SAIDA VARCHAR(2000), @DATAI DATETIME, @DATAF DATETIME DECLARE @MES INT, @DIA INT, @DIAT INT, @HORA INT, @MIN INT, @AUX VARCHAR(100) DECLARE MYCURSOR CURSOR FOR SELECT * FROM @TAB OPEN MYCURSOR FETCH NEXT FROM MYCURSOR INTO @DATAI, @DATAF, @AUX WHILE @@FETCH_STATUS = 0 BEGIN SET @SAIDA = '' SET @MES = DATEDIFF(MM,@DATAI,@DATAF) SET @DIAT = DATEDIFF(D,@DATAI,@DATAF) SET @HORA = DATEDIFF(HH,@DATAI,@DATAF) SET @MIN = DATEDIFF(MI,@DATAI,@DATAF) SET @MIN = @MIN % 60 SET @DIA = @DIAT - (@MES * 30) - 1 SET @HORA = (@HORA - (@DIAT * 24)) SET @AUX = STR(@MES,2) + ' MES(ES) ' + STR(@DIA,2) + ' DIA(S) ' + STR(@HORA,2) + ' HORA(S) ' + STR( @MIN,2) + ' MINUTO(S)' UPDATE @TAB SET INTERVALO_DATA_EXTENSO = @AUX --PRINT @AUX FETCH NEXT FROM MYCURSOR INTO @DATAI, @DATAF, @AUX END CLOSE MYCURSOR DEALLOCATE MYCURSOR SELECT INTERVALO_DATA_EXTENSO, DATAI, DATAF FROM @TAB GO Resultado: INTERVALO_DATA_EXTENSO DATAI DATAF -------------------------------------------------- ------------------------ ----------------------- 14 MES(ES) 9 DIA(S) 6 HORA(S) 0 MINUTO(S) 2003-07-05 10:00:00.000 2003-08-07 15:30:00.000 14 MES(ES) 9 DIA(S) 6 HORA(S) 0 MINUTO(S) 2003-07-05 10:00:00.000 2003-09-07 15:30:00.000 14 MES(ES) 9 DIA(S) 6 HORA(S) 0 MINUTO(S) 2003-07-05 10:00:00.000 2003-09-07 16:00:00.000 14 MES(ES) 9 DIA(S) 6 HORA(S) 0 MINUTO(S) 2003-07-05 10:00:00.000 2004-09-07 16:00:00.000 (4 row(s) affected) Considerações finais: Não sei se é útil, porém talvez valha pela curiosidade. O que foi demonstrado acima pode ser executado através de uma função (function), porém acreditem algumas versões de alguns bancos de dados proprietárias não disponibiliza uso de funções. E lembrem-se estes exemplos não passam de elocubrações. Fonte/Autor/link AUTOR: "Jothaz" Dúvidas, criticas, contribuições, correções e adições serão bem vindas.

Pelo que vi no fonte é java script: <script src="/js-global/FancyZoom.js" type="text/javascript"></script> <script src="/js-global/FancyZoomHTML.js" type="text/javascript"></script> <script src="CodaEffects.js" type="text/javascript"></script> <script src="/mint/?js" type="text/javascript"></script> Na internet você encontra várias bibliotecas de javascript prontas para usar. Por exemplo Jquery é uma delas. E esta FancyZoom.js, FancyZoomHTML.js e CodaEffects.js são outras. Vamos esperar o pessoal do fórum se manifestar.

Sinceramente ai não tem como lhe ajudar. Efetuar um JOIN sem saber por quais campos nem a ninja andreia_sp. :lol: Pelo que puder ver você esta começando a aprender o que louvavel porém sem um conhecimento minimo não da para ajudar. Acho que deverias estudar mais sobre: banco de dados, modelagem e sql. Sei que não é fácil mas é o único caminho. Não leve isso como pagação de sapa só estou lhe dando um toque e já tenho uns 20 de estrada só com informatica.

declare @table_Palavras table (Id int,data datetime,idioma varchar(20),palavra varchar(20)) insert into @table_Palavras (Id,data,idioma,palavra) values (38,'2008/12/10 15:30:30','pt','cabelo') insert into @table_Palavras (Id,data,idioma,palavra) values (39,'2008/12/10 15:30:30','en','hair') insert into @table_Palavras (Id,data,idioma,palavra) values (40,'2008/12/10 15:30:30','cro','kosa') declare @table_traducoes table (Id int,Idpalavra int,data datetime,idioma varchar(20),traducao varchar(20)) insert into @table_traducoes (Id,Idpalavra,data,idioma,traducao) values (1,38,'2008/12/10 15:30:30','en','hair') insert into @table_traducoes (Id,Idpalavra,data,idioma,traducao) values (2,38,'2008/12/10 15:30:30','es','pelo') insert into @table_traducoes (Id,Idpalavra,data,idioma,traducao) values (3,38,'2008/12/10 15:30:30','al','haar') insert into @table_traducoes (Id,Idpalavra,data,idioma,traducao) values (4,39,'2008/12/10 15:30:30','it','capelli') insert into @table_traducoes (Id,Idpalavra,data,idioma,traducao) values (5,39,'2008/12/10 15:30:30','cro','kosa') insert into @table_traducoes (Id,Idpalavra,data,idioma,traducao) values (6,39,'2008/12/10 15:30:30','viet','tóc') insert into @table_traducoes (Id,Idpalavra,data,idioma,traducao) values (6,40,'2008/12/10 15:30:30','din','hår') select * from @table_Palavras p, @table_traducoes t where p.Id = t.Idpalavra and p.palavra like 'cabelo' Temos a massa de teste agora é só lapidar. Me diga pelo que entendi você quer um busca tipo recursiva? E os niveis de busca são indefinidos? Quem fez a mnodelagem destes dados? Foi você ou é algum legado?

Sinceramente não consegui entder nadinha. Agora pelo que vi ta faltando o JOIN entre as tabelas. Por isso tá atualizando todos os registros.

Posta o códgio completa da criação da TABLE. Só vendo os pedaços não tem como sugerir nada. Se o códgio for muito extenso pode mandar para jothaz@gamil.com mas só acesso a noite pois agora estou no trampo e é bloqueado. Pelo que vi o problema é simples mas sem ver o todo não tem como ajudar.

Os TR´s realmente saltam linha e os TD´s são as celulas na mesma linha. Veja esta exemplo; <table id="minhatable" border="1" > <tr align="center"> <td> linha1, celula1 </td> <td> linha1, celula2 </td> </tr> <tr align="center"> <td> linha2, celula1 </td> <td> linha2, celula2 </td> </tr> <tr align="center"> <td colspan="2"> linha3, celula1 </td> </tr> </table> Se você quer que fique na mesma linha é só usar: <tr> <td></td> <td></td> <td></td> </tr>

Pra facilitar por favor dê um exemplo de cmo ficaria os dados nas tabelas: table_Palavras Campos: Id,data,idioma,palavra E tenho uma outra tabela: table_traducoes Campos: Id,Idpalavra,data,idioma,traducao Crie um massa de teste.

você continua embaralhando os tr´s e td´s. Tenta assim: echo "<tr><td>" . $row['cidade'] . "<td></tr>"; //cria um link para o site echo "<tr><td><a href=".$row['site'].">".$row['site']."</a></td>"; echo "<tr><td>" . $row['desc_resumida'] . "</td></tr>";

Posta a parte do códgo q cria a table facilita.

Não entedi o post. O exemplo seguinte exibe/oculta uma div com href: <html> <script> function f(){ var obj = document.getElementById('minha_div').style.display; if (obj == "none"){ document.getElementById('minha_div').style.display = 'block'; } if (obj == "block"){ document.getElementById('minha_div').style.display = 'none'; } } </script> <a href="#" onclick="f();"> <font style="color:##008000;"><b>GPX</b></font> </a> <div id="minha_div" style="border: solid 2px;display:'none'">. oioioio </div> </html>

O exemplo é para o SQL Sever mas se não me engano o MySQL tb tem declare @tab table (cod varchar(10)) insert into @tab (cod) values ('12-125-256') insert into @tab (cod) values ('12.356.963') insert into @tab (cod) values ('58696333') insert into @tab (cod) values ('586.963.33') select * from @tab where charindex('-', cod) > 0 or charindex('.', cod) > 0 or charindex(';', cod) > 0

Acho que estais embaralhando as tr´s e td´s. Tanta assim: echo "<tr><td><font face='verdana' size='3' color='blue'>" . $row['razao'] . "</td>"; echo "<td><font face='verdana' size='0' color='red'>" . $row['telefone1'] . "</td>"; echo "<td><font face='verdana' size='0' color='red'>" . $row['telefone2'] . "</td>"; echo "<td>" . $row['cidade'] . "</td></tr>";

Pelo que entendi você quer efetuar uma consulta fonética? Tipo: tais, thais, tays ou thays é isso? No SQL Sever dependendo da versão temo SOUNDEX. Dá uma pesquisada em "pesquissa fonética" pra mysql que achará várias dicas.

Select * from <nome_tabela> where <nome_campo> is null or <outro_campo> is null or <outro_campo> is null;

Qual bd? (access ou sql server) Qual versão? Fiz assim e funfionou: declare @PEDI table (NrPedido varchar(10)) insert into @PEDI (NrPedido) values ('16283') declare @LANC table (NrLanca varchar(10)) insert into @LANC (NrLanca) values ('1016283') SELECT * FROM @LANC l , @PEDI p WHERE '10' + p.NrPedido = l.NrLanca Os campos NrPedido e NrLanca são de que tipo?

Procure por slide javascript no google existem vários gratuitos e fáceis de usar.

Obrigado! Vou postanto o resto do material que tenho na medida do possivel.

No atual post prentende-se discutir/exemplificar alguns pontos que poderão serem úteis tanto no entendimento/clareza quanto na performance das queries e stored procedure. Não são regras, são apenas "dicas" cada caso é um caso. Utilize-as sempre que possível, lembrando que alguns casos poderemos perder em performance para atender determinadas situações. Esta dicas podem ser aplicadas em quase todos os bancos de dados que utilizem padrão ANSI. Uso do Select *Sempre que possível evitar o uso de select * mesmo que a Stored Procedure retorne todos as colunas de uma tabela. Com isso, garante-se a segurança e manutenabilidade da SP, pois sabe-se exatamente quais parâmetros ela retorna assim que se visualiza o seu código. Uso de > ou >= Situação: A query é: select c1,c2 from t where a > 3 e a tabela possui índice em a.. Se houver muitas linhas com a = 3, o engine do banco de dados fará scan de muitas páginas até encontrar a > 3. É mais eficiente se escrita da forma: select c1,c2 from t where a >= 4 Exists ou Not Exists De maneira geral o uso de EXISTS e IN é mais eficiente que NOT EXISTS e NOT IN. Situação: if not exists ( select a from t where a = 3 ) begin .....grupo 1 end else begin .....grupo 2 end É mais eficiente se escrita da forma if exists ( select a from t where a =3 ) begin ... grupo 2 end else begin ... grupo 1 end No SELECT de um EXISTS tomar cuidado para não colocar * ou colunas que não sejam índice cluster, pois o EXISTS não necessita retornar colunas somente verificar se a linha existe ou não. Assim, utilizar if exists: select 1 from t where a > 3 ao invés de if exists: ( select * from t where a > 3) Subqueries com cláusula de outer-join restritiva select w from outer where y = 1 and x = (select sum(a) from inner where inner.b = outer.z ) Será quebrada pelo bancod e dados nos seguintes passos select outer.z, summ = sum(inner.a) into #work from outer, inner where inner.b = outer.z and outer.y = 1 group by outer.z select outer.w from outer, #work where outer.z = #work.z and outer.y = 1 and outer.x = #work.summ O bancod de dados copia a cláusula search ( y = 1 ) para a subquery, mas não copia cláusula join. Isto porque copiando a cláusula search, sempre tornará a query mais eficiente, mas copiando a cláusula join pode em muitos casos tornar a query mais lenta. A cópia da cláusula join só é eficiente quando ela é extremamente restritiva, mas o banco de dados faz a quebra antes do otimizador atuar. Então, para tornar a query mais eficiente, conhecendo previamente a alta restritividade da cláusula join, pode-se copiar a cláusula join para a subquery como no exemplo abaixo : tab_x -> tabela grande tab_y -> tabela pequena select a from tab_x, tab_y where tab_x.coluna_valor_unico = tab_y.a and tab_x.b = ( select sum© from tabela_interna where tab_x.d = tabela_interna.e and tab_x.coluna_valor_unico = tab_y.a) Criação de tabelas dentro de stored procedures Quando uma tabela é criada e utilizada dentro de uma mesma stored procedure, o otimizador não tem conhecimento das suas estatísticas, e assume que esta tabela tem 100 linhas e 10 páginas. Se a tabela criada é muito grande, esta suposição pode levar o otimizador a calcular um plano de acesso não otimizado. Para evitar este problema, crie a tabela em uma procedure e utilize-a em outra. Isto será objeto de especificação durante o Diagrama de Cenários. Variáveis ou parâmetros na cláusula where O otimizador não tem informações sobre o valor de uma variável, mas, em tempo de compilação, sabe o valor de um parâmetro. Isso posto, a utilização de parâmetros em cláusula where, leva o otimizador a produzir um plano de acesso mais eficiente. Por exemplo, a procedure create procedure s_p1 as declare @x int select @x = b1 from t where a1 = 3 select a from t2 where b1 = @x pode ser reescrita como : create procedure s_p1 as declare @x int select @x = b1 from t where a1 = 3 exec s_p2 @x create s_p2 @x int as select a from t2 where b1 = @x COUNT x EXISTS Para testes de existência é sempre mais eficiente utilizar EXISTS do que COUNT. Quando se utiliza o COUNT o banco de dados não sabe que se está fazendo um teste de existência e continua pesquisando todas as linhas qualificadas. Já utilizando EXISTS, o banco de dados sabe que é um teste de existência e interrompe a pesquisa quando encontra a primeira linha qualificada. Este mesmo raciocínio é válido quando se utiliza COUNT no lugar de IN ou ANY. OR x UNION O banco de dados não consegue otimizar cláusulas de join ligadas por OR. Neste caso é mais eficiente ligar os conjuntos de resultados por UNION. Por exemplo : select a from tab1,tab2 where tab1.a = tab2.a OR tab1.x = tab2.x pode ser reescrito como : select a from tab1, tab2 where tab1.a = tab2.a UNION select a from tab1, tab2 where tab1.x = tab2.x A diferença é que na segunda forma, são eliminadas as linhas duplicadas, o que pode ser contornado com UNION ALL. MAX e MIN Agregados O banco de dados utiliza uma otimização especial para MAX e MIN quando há um índice na coluna agregada. Para o MIN a pesquisa é interrompida quando encontra a primeira linha qualificada. Para o MAX, o banco de dados vai diretamente para o final do índice e pega a última linha. Os casos onde estas otimizações especiais não são utilizadas: - a expressão do MAX ou MIN não é uma coluna. - a coluna do MAX ou MIN não é a primeira do índice - existe outro comando agregado na query. - existe uma cláusula de GROUP BY. - se existe cláusula WHERE, a otimização especial de MAX não é utilizada. Se houver possibilidade de se conseguir otimização especial, vale a pena separar em várias queries. É mais eficiente utilizar o índice várias vêzes, do que fazer scan table uma única vez. Em alguns casos, pode ser mais eficiente não utilizar a otimização especial do MIN. Por exemplo, se há uma cláusula where em outro índice, quanto mais restritivo for o WHERE, menos eficiente fica a otimização especial do MIN. A solução é convencer o otimizador a não utilizar a otimização especial do MIN, colocando, por exemplo, duas agregações na query. Por exemplo : select MIN(coluna1) from tab where coluna2 = <valor encontrado só no final do índice da coluna1> O banco de dados utilizará aqui a otimização especial do MIN, e fará um scan em quase todo o índice, pois a qualificação na cláusula WHERE força esta situação. Se colocarmos mais um aggregate, convenceremos o otimizador a utilizar o processo normal, criando um plano de acesso pelo índice da coluna2, neste caso, mais eficiente que a otimização especial do MIN. select MIN(coluna1), MAX[coluna2) from tab where coluna2 = <valor encontrado só no final do índice da coluna1> Joins e Datatypes Se a cláusula join utiliza datatypes diferentes, um deles será convertido para o outro. O datatype convertido é o hierarquicamente inferior. O otimizador não consegue escolher um índice na coluna que é convertida. O ideal é evitar este tipo de join, mas se não for possível, pode-se explicitamente converter o lado do join que tem o menor custo de não utilização do índice. Por exemplo : select c1,c2 from tab1, tab2 where tab1.col_char_75 = convert ( char(75), tab2.col_varchar_75 ) Parâmetros e Datatypes O otimizador pode utilizar o valor de um parâmetro para calcular o custo de um plano. Mas o banco de dados não poderá utilizar valores de parâmetros convertidos. O ideal então é garantir que o parâmetro tem o mesmo datatype da coluna com a qual ele será comparado. Por exemplo : create procedure s_p @x varchar(30) as select c1,c2 from tab where coluna_char_30 = @x pode ser reescrito como: create procedure s_p @x char(30) as select c1,c2 from tab where coluna_char_30 = @x Testar retorno de comando SQL Após um comando SQL (select, insert, update, delete) sempre é necessário testar duas variáveis para um correto processamento da Stored Procedure: @@error (código de retorno do banco de dados ) e @@rowcount (quantidade de linhas retornadas pelo comando). Estas variáveis devem ser testadas para que a SP possa dar como retorno os códigos de erro -1001 (erro banco de dados ) e -1002 (não encontrou registro). No caso do raiserror, retornar 40001 e 40002 respectivamente. Para testar siga o exemplo: declare @erro smallint, @numlin smallint select a from t where a > 3 /* sempre salvar o valor de @@error em uma variável pois para cada comando SQL o banco de dados gera um @@error. */ select @erro = @@error @numlin = @@rowcount if @erro != 0 return -1001 /* erro banco de dados */ if @numlin = 0 return -1002 /* não encontrou registro */ Stored Procedure chamadora Para as SP´s consideradas chamadoras, ou seja, aquelas que chamam outras SP´s deve-se tomar um cuidado especial com os códigos de retorno (vide quadro de códigos). Além dos códigos padronizados (0, -1001, -1002, ...) a SP ainda pode retornar códigos próprios dela durante a execução (códigos -1 a -14). Estes códigos sinalizam que houve algum tipo de problema para a execução da SP: não achou a SP, não existe permissão para executá-la, entre outras. Testar na SP chamadora estes códigos de retorno também. Exemplo: create procedure s_teste as declare @return int /* p/ código de retorno */ /* executa s_teste2 buscando seu código de retorno */ execute @return = s_teste2 /* testa retorno de s_teste2 */ if @return != 0 begin raiserror 40001 return -1001 /* erro banco de dados */ end else begin raiserror 40000 return 0 /* OK */ end Utilização do comando RAISERROR O uso do RAISERROR no código é obrigatório para as SP´s chamadoras ou que retornem múltiplas todos´s da mesma tabela ou de tabelas diferentes. Isto faz-se necessário para facilitar e viabilizar o controle de erros nas aplicações PowerBuilder. O RAISERROR deve ser colocado antes de todos os return´s do código da SP. Ver padronização dos códigos no quadro CÓDIGOS DE RETORNO. Nas demais SP´s fica a critério do coordenador de cada equipe de desenvolvimento, a decisão pela obrigatoriedade da utilização do RAISERROR. Exemplo: vide código SP do item acima. Uso de campos formato DATA (smalldatetime e datetime) Tomar bastante cuidado com a utilização de campos no formato DATA, principalmente para utilização de datas zeradas e datas com 99999999. No banco de dados este conceito perdeu o sentido pois só são aceitas datas válidas para um campo formato DATA. Assim, utilizar 1900/01/01 para representar DATA = 0 e 2070/12/31 para representar DATA = 99999999. Estas datas são os limites abaixo e acima para os campos smalldatetime. Para casos aonde este range não seja suficiente, buscar orientação com o Suporte/Adm. de Dados. Fonte/Autor/linkAUTOR: estas dicas foram retiradas da internet, livros e dos DBA`s nas empresa que trabalhei. Consequentemente foram alteradas, corrigidas e adicionadas ea gora estou compartilhando com os foristas. Caso alguém seja o autor favor postar o link para que os créditos possam ser atribuido. Dúvidas, criticas, contribuições, correções e adições serão bem vindas.