Neste mundo paga sempre o justo pelo pecador.
O pecador consegue sempre aquilo que quer sem o mínimo esforço,
enquanto o justo por mais que se esforce nunca conseguirá o que quer,
porque já alguém o deu ao pecador sem que ele para isso tivesse de se esforçar.
Por isso, ou te contentas com o que tens, ou vais ter que cometer alguns pecados por ti mesmo.
Apesar de o número de infectados em todo o mundo continuar a aumentar e de portugal já ter registado 554 infectados,
parece que a maioria da população não está a levar muito a sério esta doença que pode atingir números alarmantes de infectados e também de mortes.
O português comum ainda acha que este tipo de coisas só acontece aos outros, não a ele e por esse motivo às vezes facilita e sujeita-se a riscos desnecessários.
Por isso, por descargo de consciência e para quem estiver interessado em saber mais sobre a Gripe A, deixo aqui alguns links com informação útil sobre este assunto.
No site da DECO pode encontrar um artigo interessante com respostas claras às seguintes questões (o link encontra-se mais abaixo):
Link: http://www.deco.proteste.pt/saude/gripe-a-respondemos-as-suas-duvidas-s562971.htm
Uma outra fonte de informação é este ficheiro no formato PDF do ministério da saúde, o qual eu próprio já enviei por e-mail, já recebi e já vi impresso e afixado nos espelhos dos wc’s de algumas empresas.
Porque não fazer você o mesmo?
Mais informo que segundo o departamento de saúde britânico, o Tamiflu (medicamento actualmente recomendado para combate à doença), não deve ser tomado por crianças menores de 12 anos!
Espero que esta informação seja útil e por favor siga as recomendações existentes no site da DECO e no ficheiro aqui disponibilizado.
Obrigado.
Num programa feito em VB6 que em determinada parte do código usava alguns ADODC (Active Data Objects Data Control), surgiu-me o seguinte erro: [DBNETLIB][ConnectionOpen (Invalid Connection()).] Ligação inválida. Esclarecedor…
Este erro dava quando um dos ADODC tentava estabelecer ligação com a base de dados em SQL Server 2000.
Um colega sugeriu se não seria devido ao facto de ter atingido o número máximo de ligações…BINGO!
No SQL Server há uma propriedade que é “Maximum number of concurrent connections” e este valor é o número máximo de conexões à base de dados que podem existir ao mesmo tempo, ainda que sejam todas provenientes do mesmo utilizador e/ou máquina.
No SQLExpress 2008 este valor vem a 0 (zero) por omissão sendo que assim permite um número ilimitado de conexões.
O que eu pretendia era alterar este valor no SQL Server 2000 por query sem ter que ir às configurações.
Eis como fazê-lo:
sp_configure 'show advanced options', 1 go reconfigure go sp_configure 'user connections', 0--este é o valor máximo pretendido, coloquei zero porque quero que sejam ilimitadas go reconfigure go
Fácil, não é?
Fiquei hoje a saber de um concurso que a Vodafone está a realizar onde oferece um telemóvel por dia e ainda descontos imediatos de 30€ na compra de um dos seguintes telemóveis:
Quanto ao desconto imediato, consiste num código que deverá ser introduzido na loja online da vodafone no acto da compra.
Como já ganhei alguns e não faço intenções de os usar aqui ficam para quem quiser:
Todos os códigos têm um prazo de validade de 5 dias apartir de hoje.
Para obter mais informações, ler o regulamento, ganhar mais códigos ou tentar a sorte de ganhar um telemóvel, basta ir ao site do concurso em: http://www.veraovodafone.com
Boa sorte!
Por vezes quando estamos a desenvolver uma alteração numa aplicação já existente, há a necessidade de acrescentar, alterar ou até mesmo apagar colunas de uma tabela. Geralmente isso faz-se no arranque da aplicação numa qualquer rotina de actualização. A questão é, como controlamos se essa alteração já foi feita ou não na base de dados?
Há várias formas é certo mas pessoalmente discordo, sou contra, e abomino coisas como:
Pense comigo:
Temos tabelas e campos que são objectos numa base de dados. Estes objectos estão referenciados algures, certo? Estão nas tabelas “sysobjects” e “syscolumns”, não é?
Então porque não fazemos assim:
SELECT * FROM syscolumns LEFT JOIN sysobjects ON syscolumns.id = sysobjects.id WHERE syscolumns.name = 'campo' AND sysobjects.name = 'tabela'
Se devolver algum registo é porque o campo existe e assim ficamos a saber que se pretendemos apagar este campo o drop não irá dar erro, se não devolver é porque não existe e é seguro criá-lo!
Ou por exemplo, se quisermos só alterar um campo que era smalldatetime e agora queremos que seja datetime:
SELECT * FROM syscolumns LEFT JOIN sysobjects ON syscolumns.id = sysobjects.id WHERE syscolumns.name = 'campo' AND sysobjects.name = 'tabela' AND syscolumns.xtype = 61
Se devolver algum registo é porque o campo já está como datetime e não é preciso fazer mais nada, se não devolver nenhum registo é porque o campo ainda não é datetime e então podemos fazer o nosso alter column!
Ok, eu sei que isto obriga a que seja feita uma instrução para cada alteração enquanto que os outros métodos controlam-nas em “packs” mas um select não é assim tão lento quanto isso e além do mais podemos reduzir tudo (select + add / alter / drop) a uma só instrução:
IF NOT EXISTS (SELECT autoval FROM syscolumns LEFT JOIN sysobjects ON syscolumns.id = sysobjects.id WHERE syscolumns.name = 'campo' AND sysobjects.name = 'tabela') ALTER TABLE tabela ADD campo tinyint NOT NULL DEFAULT 1
Se conhecer algum método mais simples e mais eficaz do que este, por favor diga-me.
Até lá irei continuar a usá-lo.
Por vezes criámos tabelas, na maioria secundárias, às quais atribuímos a propriedade de “identity” a um campo que irá funcionar como chave. Assim, não temos que nos preocupar com a numeração e consistência dessa mesma chave pois sempre que é acrescentado um novo registo, o engine do MS SQL trata de incrementar o contador e atribuir um novo valor a esse campo. Mas o que acontece quando queremos ser nós a atribuir esse valor? É simples, não nos é permitido.
Exemplo:
Esta é a nossa tabela…
CREATE TABLE [teste] ( [id] [int] identity (1, 1) NOT NULL, [nome] [nvarchar] (255) NOT NULL, constraint [pk_teste] PRIMARY KEY clustered ([id]) ON [PRIMARY] ) ON [PRIMARY]
…e este é o nosso insert, o qual não irá funcionar pois estámos a tentar atribuir um valor (3) a um campo que é identity (id).
INSERT INTO teste (id, nome) VALUES (3,’um texto qualquer’)
Para que o nosso insert funcione temos que em primeiro lugar activar o insert em identities…
SET identity_insert [teste] ON
…só depois fazemos o nosso insert…
INSERT INTO teste (id, nome) VALUES (1,’um texto qualquer’)
…e finalmente voltamos a desactivar o insert em identities.
SET identity_insert [teste] off
Resumindo:
SET identity_insert [teste] ON INSERT INTO teste (id, nome) VALUES (1,’um texto qualquer’) SET identity_insert [teste] off
Ter em atenção que o facto de termos colocado um valor manualmente numa coluna identity, não influencia o incremento. Isto é, no próximo insert, o valor atribuído à coluna “id” irá ser sempre o valor máximo + 1.
Alguma dúvida? Basta comentar.
Há uns dias ligou-me uma colega de trabalho de uma empresa onde estive há uns anos, perguntando se a podia ajudar num problema relacionado com o MS SQL Server e o software Primavera.
Pelo que consegui perceber dos erros que o Primavera reportava, a base de dados pareceu-me estar com sérios problemas e recomendei um rebuild.
O problema é que não tinha como o fazer pois apesar de ter o MS SQL Server 2000 instalado, não tinha qualquer ferramenta de manutenção.
Aconselhei a instalar o Microsoft SQL Server Management Studio Express pois é gratuito e indiquei os comandos a executar.
As bases de dados, por mais robustas que sejam, precisam sempre de cuidados e manutenção, caso contrário podem começar a acontecer coisas estranhas e podemos vir a perder informação importante.
O que precisamos fazer para reparar uma base de dados MS SQL Server?
Ligados ao servidor, clicamos em “New Query”:
O que irá abrir uma janela em branco para executarmos as nossas querys.
ALTER DATABASE nome-da-base-de-dados SET single_user
dbcc checkdb ('nome-da-base-de-dados', repair_rebuild)
Geralmente é o suficiente mas por vezes a base de dados está tão danificada que não é possível reparar sem que para isso tenhamos de perder alguma informação. Se estivermos dispostos a tal, então o comando deverá ser o seguinte:
dbcc checkdb ('nome-da-base-de-dados', repair_allow_data_loss)
ALTER DATABASE nome-da-base-de-dados SET multi_user
Resumindo:
ALTER DATABASE nome-da-base-de-dados SET single_user dbcc checkdb ('nome-da-base-de-dados', repair_rebuild) ALTER DATABASE nome-da-base-de-dados SET multi_user
Se tudo correr bem, a nossa base de dados estará de novo operacional.
Boa sorte!
Pois bem, hoje vinha a sair da N1 para entrar no IP1 quando reparei que à minha frente vinha um automóvel muito robusto, elegante até que transmitia uma sensação de potência. Era um BMW X6, um carro que, mesmo não sendo eu um amante de automóveis, considero no mínimo digno de respeito.
Após entrarmos no IP1, o SUV deu pisca para ultrapassar um outro carro que ía à sua frente e eu pensei “pronto vai já desaparecer da minha vista”, mas a verdade é que mesmo ganhando velocidade ele continuava à minha frente e como eu estava com pressa, dei pisca, coloquei-me na terceira faixa e quem desapareceu fui eu. Apesar de conduzir um Toyota Corolla e saber à partida que o X6 tem mais do dobro da cilindrada não deixei de me sentir orgulhoso do meu carrinho.
Contudo, algumas dezenas de metros à frente o trânsito levou-me a diminuir a velocidade e ainda ao longe eis que o homenzinho do BMW faz o gosto ao dedo e deu-me sinal de luzes. Fiquei sem saber o que ele queria, passar por cima? Ultrapassar não deveria ser porque assim que o trânsito fluiu e me deixou aumentar a velocidade, o X6 ficou para trás de novo…
Confesso que cheguei a ficar desapontado com este SUV da BMW, mas depois lembrei-me, talvez não seja problema do carro mas sim do condutor… 
Diga-me o que acha.
Num país onde cada vez é mais difícil arranjar emprego, há ainda a forte possibilidade de, quando um cidadão finalmente encontra um emprego, esse ser a recibos verdes.
Felizmente não me encontro nessa situação mas hoje resolvi fazer uma pesquisa sobre esse tema e quanto mais lia mas ficava revoltado com a maneira como tanto as entidades patronais como o governo, exploram aqueles que apenas querem trabalhar de uma forma honesta. Já algumas vezes ouvi, em tom de anedota usarem a expressão “pagar para trabalhar” mas depois do que li e das contas que fiz, essa expressão afinal não tem tanta piada assim…
Se começou ou vai começar a exercer actividade passando recibos verdes e anda desesperadamente à procura de respostas, vou deixar aqui um resumo de tudo o que consegui apurar para que não tenha de perder mais tempo pesquisando.
Segurança Social: Ao contrário dos trabalhadores por conta de outrem que descontam 11% da remuneração para a segurança social, quem passa recibos verdes deve descontar pelo regime obrigatório 25,4% do valor do escalão, ou no caso da mesma ser inferior a um IAS (Indexante de Apoios Sociais), deverá tomar como base de cálculo, não a remuneração mas sim o IAS que é de 407 euros. Esta obrigatoriedade só existe após o primeiro ano (o primeiro ano de actividade é isento) e só se o total anual for superior a seis IAS e se assim for, o desconto é feito com base no valor do escalão ao qual a remuneração pertence. Os escalões são os seguintes:
1º € 596,79
2º € 795,72
3º € 994,65
4º € 1.193,58
5º € 1.591,44
6º € 1.989,30
7º € 2.387,16
8º € 4.774,32
IRS: Se não auferir mais de 10.000 euros anuais em recibos verdes, a taxa de IRS é de 20%. Poderá optar por fazer retenção na fonte ou não, sendo que a primeira hipótese poupa-o de surpresas desagradáveis na altura de entregar a declaração de IRS.
IVA: É obrigatório liquidar o IVA se num ano ultrapassar o rendimento ilíquido de 10.000 euros ou se tiver optado por um regime com contabilidade organizada.
Exemplo: Vou tomar como exemplo, alguém que passa recibos verdes de 600 Euros. Neste caso o valor ultrapassa o primeiro escalão da segurança social pelo que irei usar o segundo. No que diz respeito ao IRS vou optar pela retenção na fonte e como não excede os 10.000 Euros anuais, irei ignorar o IVA.
Sendo assim:
Recibo Verde = 600 Euros
Segurança Social = -202,11 Euros
IRS = -120 Euros
Liquido = 277,89
Hmm…será que me enganei em algum lado? Ou será que andam a gozar com quem trabalha?
Faça as contas e ajude-me a descobrir. Tudo o que aqui coloquei é o resumo do que poderá encontrar pesquisando na internet mas aconselho-o a procurar o centro de segurança social mais próximo e a colocar todas as dúvidas porque cada caso é um caso.
Espero tê-lo ajudado, boa sorte!
Bem-vindo ao meu blog. Este é apenas o primeiro de muitos posts e como tal não tenciono começar logo a despejar conteúdo. Além disso ontem foi Natal, a passagem de ano está à porta e durante esta altura não acredito que esteja por aí alguém interessado em ler logo o primeiro post do meu blog…ou estou enganado? Só há uma maneira de me provar que estou errado, comente… 
Comentários Recentes