Well, it's taken over a year but it has finally arrived. I started writing the book back in Aug 2006. I finished in late Jan 2007 and the technical editor finished his work in March. Now, In Jan 2008, EnterpriseDB: The Definitive Reference is available. I'm glad I didn't wait for the movie. ;-)
It's kind of ironic. Just this morning, I posted that I am working on my second book. My wife called me at work and told me two boxes of books had arrived. 2008 is turning out to be a good year. I'll have some additional news in the near future.
Anyway, the book looks good. I've already found a few typos and grammar errors just skimming around. I like the font and the pages look really crisp. All in all, I have to say I am very happy that the book is out.
Check out some photos:
I think I want to give a couple away. Maybe some kind of contest for the blog readers. Any ideas of something fair? I am willing to pay shipping for a couple but that would only be here in the US. Overseas shipping gets expensive.
LewisC
Thursday, January 3, 2008
My Book Has Been Printed
Saturday, October 27, 2007
Continuación %ROWTYPE
A few days ago, I posted an entry, Anchored Declarations - %TYPE and %ROWTYPE. That article talked about using anchored declarations in your PL/SQL code.
PeteF ask a couple of questions about that post:
Inglés:
Nice little article - I have a couple of questions... Is there any way to utilise the %rowtype attribute from within a trigger i.e. can I easily populate a rowtype variable with all the old (or new) columns in one shot? Number two - is there an easy way to write the rowtype variable back to the DB without having to mention every column name? As you say in your article - all sacrilege I'm sure but hey ;) tia Pete
Español
Niza poco el artículo - Tengo un par de preguntas ... ¿Hay alguna forma de utilizar el atributo de rowtype% dentro de un disparador es decir que fácilmente puede rellenar el rowtype variable con todas las viejas (o nuevas) las columnas de una sola? Número dos, hay una forma sencilla de escribir la variable de rowtype al PP, sin tener que mencionar el nombre de columna? Como usted dice en su artículo, todos los sacrilegio estoy seguro, pero bueno;) Pete tia
Pete - No puedo ayudarle en la pregunta # 1. Por lo que sé, usted tiene que hacer referencia a cada una de las columnas por separado cuando se utiliza :new y :old. Hay que ser agradable ser capaz de ceder todo en una marejada foop pero por desgracia, :new y :old son seudo columnas, en contraposición a los registros.
Sobre la pregunta, el número 2, la respuesta es afirmativa. Puedes seleccionar una rowtype variables, hacer algunos cambios y, a continuación, inserte de nuevo.
declare
v_emp_rec employees%rowtype;
begin
select *
into v_emp_rec
from employees
where rownum = 1;
v_emp_rec.last_name := 'Lewis';
v_emp_rec.first_name := 'Cunningham';
v_emp_rec.email := 'lewis@email.com';
v_emp_rec.employee_id := 9999;
insert into employees values v_emp_rec;
end;
/
En ésta, que ha cambiado los campos requeridos (PK y el mensaje que es una clave única) y el nombre y, a continuación, inserta la fila como una fila nueva.
Schwierman también publicó un comentario:
Inglés:
Number two...
Have you tried the bulk collect update statement. I am using a table array, but, maybe a rowtype would work.
FORALL x IN 1 .. ptbl_lp_io.COUNT SAVE EXCEPTIONS
UPDATE lp
SET ROW = ptbl_lp_io (x)
WHERE lp_id = ltbl_lp_id (x);
Español
Número dos ...
Has intentado recoger la mayor parte de actualización. Estoy utilizando una tabla matriz, pero tal vez un rowtype de trabajo.
FORALL x IN 1 .. ptbl_lp_io.COUNT SAVE EXCEPTIONS
UPDATE lp
SET ROW = ptbl_lp_io (x)
WHERE lp_id = ltbl_lp_id (x);
Creo que se pete responder a la segunda pregunta del uso de bulk collect. Un completo ejemplo de ello es:
SQL> CREATE TABLE employees_new AS SELECT * FROM employees WHERE ROWNUM < 1;
Table created.
SQL> SELECT COUNT(*) FROM EMPLOYEES;
COUNT(*)
----------
107
SQL> SELECT COUNT(*) FROM employees_new;
COUNT(*)
----------
0
SQL> DECLARE
2
3 type arr_emp_recs IS TABLE OF employees % rowtype;
4 v_emp_rec arr_emp_recs;
5 BEGIN
6
7 SELECT *
8 bulk collect
9 INTO v_emp_rec
10 FROM employees;
11
12 FORALL x IN 1..v_emp_rec.COUNT
13 INSERT INTO employees_new VALUES v_emp_rec(x);
14
15 COMMIT;
16
17 END;
18 /
PL/SQL procedure successfully completed.
SQL> SELECT COUNT(*) FROM employees_new;
COUNT(*)
----------
107
SQL>
Declaraciones anclado - %TYPE y %ROWTYPE
Cuando se declara una variable, hay que darle un tipo de datos y de un tamaño.
Vamos a suponer por un momento que tengo una tabla que se parece a esto:
SQL> desc employees
Name Null? Type
----------------------------------------- -------- ----------------------------
EMPLOYEE_ID NOT NULL NUMBER(6)
FIRST_NAME VARCHAR2(20)
LAST_NAME NOT NULL VARCHAR2(25)
EMAIL NOT NULL VARCHAR2(25)
PHONE_NUMBER VARCHAR2(20)
HIRE_DATE NOT NULL DATE
JOB_ID NOT NULL VARCHAR2(10)
SALARY NUMBER(8,2)
COMMISSION_PCT NUMBER(2,2)
MANAGER_ID NUMBER(6)
DEPARTMENT_ID NUMBER(4)
SQL>
Podría crear un pl/sql- código de la unidad que acceder a algunas de estas columnas. Por ejemplo:
DECLARE
v_employee_id NUMBER(6);
v_hire_date DATE;
v_last_name VARCHAR2(25);
BEGIN
SELECT employee_id, last_name, hire_date
INTO v_employee_id, v_last_name, v_hire_date
FROM employees
WHERE rownum = 1;
END;
En este fragmento de código, declaró el número 6 dígitos de longitud, una fecha y un varchar2 de 25 caracteres de largo. Aunque estos tamaños coinciden con mi cuadro, hay una forma mejor de hacer esto:
DECLARE
v_employee_id employees.employee_id%TYPE;
v_hire_date employees.hire_date%TYPE;
v_last_name employees.last_name%TYPE;
BEGIN
SELECT employee_id, last_name, hire_date
INTO v_employee_id, v_last_name, v_hire_date
FROM employees
WHERE rownum = 1;
END;
Mismos resultados, pero ahora mi software es sólo un poco más fácil de mantener. Si yo uso constantemente %TYPE todo mi código, puede cambiar el tamaño de columna con un poco menos preocupación. Técnicamente, puede ser capaz de cambiar los tipos de datos y estar bien, pero he encontrado que, en la práctica, cuando el usuario cambia los tipos de datos, se necesitará revisar una gran cantidad de su código.
%TYPE es usado cuando usted se refiere son las columnas individuales. Hay muchos casos en donde será usado toda una fila. En lugar de crear manualmente un tipo de registro, puede declarar una variable de %ROWTYPE. Por ejemplo, a continuación voy a seleccionar todas las columnas de mi tabla:
DECLARE
v_employees employees%ROWTYPE;
BEGIN
SELECT *
INTO v_employees
FROM employees
WHERE rownum = 1;
END;
Esta recoge la totalidad de las columnas y los ponga a disposición en su programa. Puede detallar cada una de las columnas en su lista de selección como este:
DECLARE
v_employees employees%ROWTYPE;
BEGIN
SELECT employee_id, first_name, last_name,
email, phone_number, hire_date, job_id, salary,
commission_pct, manager_id, department_id
INTO v_employees
FROM employees
WHERE rownum = 1;
END;
Si lo hace detallar cada una de las columnas, es necesario mantenerlos en las columnas en el mismo orden que se declaran en su mesa. Si añade una columna de la tabla, tendrá que modificar su código.
"SELECT *" es más fácil de leer. Asimismo, en los casos en que es necesario recoger las nuevas columnas (por lo general, los procedimientos de mantenimiento tipo), "SELECT *" recoge nuevas columnas con un solo recompilar, en contraposición a la necesidad de añadir manualmente las columnas.
Este es un caso en el que usted necesita para hacer una llamada en cuanto a si un "SELECT *" es una mala cosa o no. Yo no tengo un problema con el "SELECT *" en estos casos. En realidad, me atrevería a decir incluso recomendar que en el caso de que usted realmente necesita todas las columnas (o incluso la mayoría de las columnas). Me doy cuenta de que es una herejía para muchos. Oh, bien.
Una última nota es que %TYPE y %ROWTYPE también como parámetros de trabajo y es una gran manera de enviar datos en torno a que es arrastrada desde su base de datos. Por ejemplo:
CREATE OR REPLACE
PROCEDURE get_employee( p_employee_rec OUT employees%ROWTYPE )
AS
BEGIN
SELECT *
INTO p_employee_rec
FROM employees
WHERE rownum = 1;
END;
Este fragmento de código devolverá un registro de los datos del empleado a la llamada de rutina.
%TYPE y %ROWTYPE se llaman anclado declaraciones. Básicamente, usted es el tipo de datos de su anclaje declaraciones a la columna de definiciones en su base de datos. Además de asegurar que sus datos tipos y tamaños siempre coinciden, se hace más fácil ya que el código no tiene que buscar los tamaños, así como cada vez que escribir un pedazo de código.
Utilice anclado declaraciones. Utilizar de manera consecuente y la gente que sigue a lo largo de atrás para mantener su código gracias.
Saturday, October 13, 2007
Por favor, ayúdame a cabo y responder a una pregunta
Como es posible que puedas decir, no soy un experto español. Quería crear un blog para que más personas puede ayudar a empezar con Oracle por lo que optaron por crear un blog que se escribe en español. Yo uso el traductor Google herramienta para crear este blog de escritos que he hecho en inglés.
Entonces, mi pregunta es, ¿encontraste esta página útil? Aun con la mala gramática? ¿Le gustaría a mí seguir con la publicación?
Gracias de antemano por su respuesta. Soy consciente de que tomar el tiempo para hacerlo.
LewisC
¿Qué es una base de datos de enlace?
Una base de datos de enlace es la forma de Oracle le permite conectarse desde una base de datos a otro. Un enlace a la base de datos de una base de datos remota utilizando una ID y una contraseña al igual que un usuario, pero sólo permite el acceso programático.
Base de datos permitirá a los vínculos de procesamiento distribuido. Replicación es un excelente ejemplo de una aplicación que utiliza la base de datos enlaces. Replicación de bases de datos Oracle utiliza vínculos con el movimiento de datos de una base de datos a otro.
Un vínculo es una base de datos en un solo sentido conducto que le permita realizar LMD contra bases de datos remotas al igual que lo haría en contra de una base de datos local. Su SQL no es necesario cambiar los requisitos, salvo que la base de datos que desea acceder.
En segundo lugar, la vinculación requiere de bases de datos remotas de base de datos que se definan a su servidor. El cliente pueda que no saben nada acerca de una base de datos y que todavía existe la posibilidad de crear un enlace. Lo inverso también es válido; Si el cliente es consciente de una base de datos, pero el servidor no es, no puede crear un vínculo.
Ejemplos de la creación y uso de PP Enlaces
Seleccione sysdate doble de la tabla en una base de datos remota RemoteDB nombres de los usuarios conectados mediante un enlace:
CREATE DATABASE LINK MyRemoteDB USING 'RemoteDB';
SELECT sysdate FROM DUAL@MyRemoteDB;
Ejecutar un procedimiento almacenado en la base de datos remota:
BEGIN
runProc@MyRemoteDB;
END;
Ejecuta una función envasados en la base de datos remota:
DECLARE
var1 VARCHAR2(10);
BEGIN
Var1 := runFunc@MyRemoteDB;
END;
Crear una cuenta utilizando el seleccionado anteriormente:
CREATE OR REPLACE VIEW Remote_Sysdate_VW AS
SELECT sysdate AS remoteSysdate
FROM DUAL@MyRemoteDB;
SELECT * FROM remote_sysdate_vw;
¿Cuáles son los NCHAR y NVARCHAR2 tipos de datos?
Usted podrá declarar NVARCHAR2 lugar de VARCHAR2. NVARCHAR2 se utiliza para almacenar los conjuntos de caracteres Unicode. Yo, personalmente, nunca han tenido un uso para NVARCHAR2. Si escribir aplicaciones multilingües y utilizar un juego de caracteres Unicode, en lugar de utilizar NVARCHAR2 VARCHAR2. CHAR también tiene un correspondiente NCHAR.
Largo restricciones son las mismas que un VARCHAR2 y UTF8 puede almacenar 32767 dividido por 2 y UTF16 puede almacenar 32767 dividido por 3. No se puede mezclar y combinar VARCHAR2 NVARCHAR2 y las variables. Usted debe escoger uno o el otro y se pegan con él. Ambos están disponibles en SQL y PL / SQL.
What is the CHAR Datatype?
CHAR es una longitud fija de datos. Si no se especifica un tamaño máximo, el valor por defecto es 1. El tamaño máximo para un carácter en una columna es de 2000 bytes y 32767 en PL / SQL.
Yo bastante considerar CHAR a ser un legado de datos. Algunas personas utilizan CHAR (1) para almacenar indicadores (Y, N, etc) o como una tabla BOOLEAN. Prefiero usar VARCHAR2 incluso en esos casos.
Un caso que puede estar justificada (en mi opinión, de todos modos, esta es mi opinión) sería rellenar los datos desde o hacia un modelo de informe que tendrá que ser reproducida. Por ejemplo, si lee un archivo de longitud fija, y puede que necesite para generar el archivo de longitud fija que en el futuro, que se va a guardar su conversión de algunos generales por el almacenamiento de los datos en una longitud fija de datos (es decir CHAR).
Una de las áreas que la gente meterse en problemas son CHAR y VARCHAR2 comparaciones. Si se quede con VARCHAR2, usted no tendrá problemas.
