Considere os seguintes comandos SQL (padrão ANSI) executado...

Alternativa Correta: A - VINICIUS, JOÃO, MARCOS

Para entender essa questão, precisamos compreender como o SQL lida com transações, que são sequências de operações executadas como uma única unidade de trabalho. As transações garantem que um conjunto de comandos SQL seja completado com sucesso antes que os dados sejam realmente confirmados no banco de dados, utilizando comandos como COMMIT e ROLLBACK.

No contexto desta questão, o comando CREATE TABLE é usado para criar uma tabela chamada "ALUNO" com duas colunas: ALUNO_ID e NOME. Após essa criação, vários comandos INSERT INTO são executados para adicionar registros à tabela.

A transação executada realiza os seguintes passos:

• INSERT para 'VINICIUS' e 'JOÃO' seguido de um COMMIT: Isso confirma esses dois dados no banco de dados, ou seja, eles estão definitivamente inseridos.
• INSERT para 'OSMAR' seguido de um ROLLBACK: Isso desfaz essa inserção, então 'OSMAR' não é adicionado à tabela.
• INSERT para 'MARCOS' seguido de outro COMMIT: Isso confirma a inserção de 'MARCOS', adicionando-o à tabela.

Portanto, ao final de todas essas operações, os nomes efetivamente inseridos e confirmados na tabela "ALUNO" são: VINICIUS, JOÃO, e MARCOS.

As alternativas incorretas são justificadas da seguinte forma:

• B - VINICIUS, JOÃO: Incorreta porque não considera a inserção e confirmação de 'MARCOS'.
• C - VINICIUS, JOÃO, OSMAR, MARCOS: Incorreta porque inclui 'OSMAR', que foi removido pelo ROLLBACK.
• D - OSMAR, MARCOS: Incorreta porque 'OSMAR' não foi confirmado, e 'VINICIUS' e 'JOÃO' foram ignorados.
• E - MARCOS, JOÃO: Incorreta porque ignora 'VINICIUS' e inclui 'JOÃO' sem a sequência correta.

Gostou do comentário? Deixe sua avaliação aqui embaixo!

INSERT INTO "ALUNO"( "ALUNO_ID", "NOME") VALUES
(3, 'OSMAR');
ROLLBACK;

Se comitou não tem rollback. Se fosse possível fazer rollback de algo comitado, o commit não teria valor, pois, poderia ser revertido a qualquer momento. Isso seria desastroso, pois, poderia incorrer em milhares de inconsistências. Imagine por exemplo que você insere um registro PAI em uma transação e depois insere milhares de filhos em outras e aí se arrepende e quer dar ROLLBACK no registro Pai ? Sem dúvida um desastre, seja por inconsistência, ou por um movimento de I/O sem precedentes para desfazer todas as transações influenciadas por essa.

Essa é fácil , a questão só deu ROLLBACK no OSMAR mesmo , como o amigo disse , se comitou não tem roolback ;) 

A) VINICIUS, JOÃO, MARCOS

CREATE TABLE "ALUNO" 

( "ALUNO_ID" integer NOT NULL, "NOME" text, 

CONSTRAINT "PK_ALUNO" PRIMARY KEY ("ALUNO_ID") );

--Criando Tabela Aluno com os campos ALUNO_ID do tipo integrer e não nula

-- Dirá que o campo ALUNO_ID é uma chave primária

--"PK_ALUNO" referencia que naquela tabela , esse campo é um Primary Key

--NOME CRIA-SE um campo nome do tipo "TEXT"

obs: NOT Null - Não pode ser Nulo.

Chave primária ou PK ou Primary ket = é uma colina de cominação mínima cujo o valor distinguem uma linha das tabelas. ou seja, Não pode ser repetir, é única e se auto incrementa.

--INSERT

INSERT INTO "ALUNO"( "ALUNO_ID", "NOME") VALUES (1, 'VINÍCIUS'); 

INSERT INTO "ALUNO"( "ALUNO_ID", "NOME") VALUES (2, 'JOÃO'); COMMIT;

INSIRA   na tabela Alunos os valores de Vininicius e João

ATENÇÂO:

COMMIT: efetua a transação e os dados são persistidos na tabela.

INSERT INTO "ALUNO"( "ALUNO_ID", "NOME") VALUES (3, 'OSMAR'); ROLLBACK;

INSERE O Dado Osmar na tabela Aluno porém o ROLLBACK desfaz a transação.

 INSERT INTO "ALUNO"( "ALUNO_ID", "NOME") VALUES (4, 'MARCOS'); COMMIT;

Efetua a transação do Marcos nesta linha.

VINICIUS, JOÃO, MARCOS é o gabarito.