jueves, 25 de octubre de 2012

Tomcat - user password


Hola, en el directorio conf de tu TOMCAT_HOME (lugar donde has instalado el Tomcaten tu máquina), se encuentra el archivo tomcat-users.xml .

Dentro de ese archivo agrega una entrada 'user' como:

<user username="administrador" password="administrador" roles="admin,manager"/>

Luego ya podrás adminstrar tu tomcat con ese usuario y password.

http://localhost:8080/manager/html/list

viernes, 12 de octubre de 2012

Genexus Busines Component <--> XML


Busines Component -->  XML
&Archivo.Open(&RutaOUT1)
&Producto_BC = new()
For each
&Producto_BC.Load(ProductoCodigo)
exit
EndFor
&Serializado = &Producto_BC.ToXml(False)
&Archivo.WriteRawText(&Serializado)
&Archivo.Close()

Busines Component <-  XML

&Producto_BC = new()
&ArchivoInput.Open(&RutaIN1)
    &ArchivoInput.Read()
&Serializado=&ArchivoInput.ReadRawXML()
&ArchivoInput.Close()
&Producto_BC.FromXml(&Serializado)
&Producto_BC.Save()
If &Producto_BC.Fail()
For &message in &Producto_BC.GetMessages()
msg(&message.Description)
EndFor
else
Commit
EndIf

jueves, 4 de octubre de 2012

Factura Electrónica


(WSAA) Autenticación y Autorización  de WebServices  perteneciente a la AFIP.
(EE) Entes Externos a la AFIP
(CEE) Computador de Entes Externos a la AFIP
(WSN) WebServices de Negocio ofrecidos por la AFIP
(TA) Ticket de Acceso
(TRA) Ticket de Requerimiento de Acceso

El WSAA realiza la verificación del TRA y si el requerimiento es correcto, devuelve un mensaje
que contiene el TA que habilita al CEE a utilizar el WSN solicitado. El TA deberá ser utilizado por el
CEE para acceder al WSN.
http://slproweb.com/products/Win32OpenSSL.html

https://servicios1.afip.gov.ar/test.asp
https://wswhomo.afip.gov.ar/wsfev1/service.asmx

https://wsaahomo.afip.gov.ar/ws/services/LoginCms


https://fwshomo.afip.gov.ar/wsmtxca/services/MTXCAService


http://199.238.156.186/afip/ticketcontent.php
set OPENSSL_CONF=c:\OpenSSL-Win64\bin\openssl.cfg
http://www.afip.gob.ar/ws/WSAA/cert-req-howto.txt
http://www.sistemasagiles.com.ar/trac/wiki/ManualPyAfipWs
http://www.afip.gov.ar/ws/WSAA/AFIP-WS-Arquitectura.pdf
http://www.afip.gob.ar/ws/WSAA/Especificacion_Tecnica_WSAA_1.2.0.pdf
http://www.afip.gob.ar/fe/documentos/manualdesarrolladormtxv0.pdf
http://www.afip.gob.ar/ws/WSFE/WSFE-ManualParaElDesarrollador-090317.pdf
http://www.afip.gob.ar/ws/#WSFE
http://www.afip.gob.ar/ws/WSFE/WSFE-FuncionamientoGeneralDelServicioWeb-090731.pdf
http://www.afip.gob.ar/ws/WSFE/WSFE-GuiaAdicionalParaElProgramador.pdf


miércoles, 3 de octubre de 2012

Java Llamar Garbage Collector


  public void pasarGarbageCollector(){

        Runtime garbage = Runtime.getRuntime();

        System.out.println(“Memoria libre antes de limpieza:”+ garbage.freememory());

        garbage.gc();

      System.out.println(“Memoria libre tras la limpieza: “+ garbage.freememory());

    }

}

martes, 18 de septiembre de 2012

Genexus - Quitar una extensión

Open Knowledge Base:

Knowledge Base at 'C:\' contains items that GeneXus doesn't know how to handle and will therefore be inaccessible.


It is likely that the Knowledge Base has been previously opened with a GeneXus installation which had extensions that are not present in the current one.



delete from Entity where
 EntityTypeId = 
(select EntityTypeId from EntityType where EntityTypeName = 'WebPanelDesigner')

 delete from EntityVersion where EntityTypeId = 
(select EntityTypeId from EntityType where EntityTypeName = 'WebPanelDesigner') 

delete from EntityVersionComposition where ComponentEntityTypeId = 
(select EntityTypeId from EntityType where EntityTypeName = 'WebPanelDesigner') 

delete from EntityVersionComposition where CompoundEntityTypeId = 
(select EntityTypeId from EntityType where EntityTypeName = 'WebPanelDesigner') 

delete from ModelCrossReference where FromEntityTypeId = 
(select EntityTypeId from EntityType where EntityTypeName = 'WebPanelDesigner') 

delete from ModelCrossReference where ToEntityTypeId = 
(select EntityTypeId from EntityType where EntityTypeName = 'WebPanelDesigner') 

delete from ModelEntityHistory where EntityTypeId = 
(select EntityTypeId from EntityType where EntityTypeName = 'WebPanelDesigner') 

delete from ModelEntityOutput where EntityTypeId = 
(select EntityTypeId from EntityType where EntityTypeName = 'WebPanelDesigner') 

delete from ModelEntityProperty where EntityTypeId = 
(select EntityTypeId from EntityType where EntityTypeName = 'WebPanelDesigner') 

delete from ModelEntityToTable where EntityTypeId = 
(select EntityTypeId from EntityType where EntityTypeName = 'WebPanelDesigner') 

delete from ModelEntityVersion where EntityTypeId = 
(select EntityTypeId from EntityType where EntityTypeName = 'WebPanelDesigner')

delete from EntityType where EntityTypeName = 'WebPanelDesigner'

jueves, 30 de agosto de 2012

Genexus Evolution - Imprimir PDF

El procedimiento debe tener:

Rules:
output_file("Miimpresion","pdf");

Main Program: True

Call Protocol: HTTP
Report to: Screen

miércoles, 18 de julio de 2012

Genexus Evolution Configuraciones Tips

En Generador:

Reorganization Options -nogui -ignoreresume
Create  Database Options -nogui -noverifydatabaseschema -ignoreresume

martes, 17 de julio de 2012

lunes, 16 de julio de 2012

Genexus Java Tips

Puesta en producción de aplicaciones GX-Java


http://www.gxtechnical.com/gxdlsp/pub/genexus/java/technicalpapers/8.0/puestaproduccion.htm

Distribución de programas de reorganización

 

http://www.gxtechnical.com/gxdlsp/pub/genexus/java/docum/manuals/8.0/mjavag10.htm

Deployment Wizard y Developer Menus


http://www.gxtechnical.com/gxdlsp/pub/genexus/java/docum/manuals/8.0/mjavag2.htm


Indice Manual Generador Java Versión 8.0

http://www.gxtechnical.com/gxdlsp/pub/genexus/java/docum/manuals/8.0/manualjavaindice.htm

viernes, 8 de junio de 2012

GENEXUS Rule Triggering Events

Rule Triggering Events




Most transaction rules allow us to add a triggering event or time to them whenever necessary.
By adding a triggering event or time to a rule, we will be indicating that the rule will have to be executed at the particular time specified.

Rule Triggering Order

When a Transaction has been confirmed, the events will be triggered in the following order:

lunes, 28 de mayo de 2012

Triggers en Transact SQL


Triggers en Transact SQL

    Un trigger( o desencadenador) es una clase especial de procedimiento almacenado que se ejecuta automáticamente cuando se produce un evento en el servidor de bases de datos.

    SQL Server proporciona los siguientes tipos de triggers:

Trigger DML, se ejecutan cuando un usuario intenta modificar datos mediante un evento de lenguaje de manipulación de datos (DML). Los eventos DML son instrucciones INSERT, UPDATE o DELETE de una tabla o vista.
Trigger DDL, se ejecutan en respuesta a una variedad de eventos de lenguaje de definición de datos (DDL). Estos eventos corresponden principalmente a instrucciones CREATE, ALTER y DROP de Transact-SQL, y a determinados procedimientos almacenados del sistema que ejecutan operaciones de tipo DDL.
Trigger DML.

    Los trigger DML se ejecutan cuando un usuario intenta modificar datos mediante un evento de lenguaje de manipulación de datos (DML). Los eventos DML son instrucciones INSERT, UPDATE o DELETE de una tabla o vista.

    La sintaxis general de un trigger es la siguiente.


CREATE TRIGGER <Trigger_Name, sysname, Trigger_Name>

ON <Table_Name, sysname, Table_Name>

AFTER <Data_Modification_Statements, , INSERT,DELETE,UPDATE>

AS

BEGIN

-- SET NOCOUNT ON added to prevent extra result sets from

-- interfering with SELECT statements.

SET NOCOUNT ON;

-- Insert statements for trigger here

END

    Antes de ver un ejemplo es necesario conocer las tablas inserted y deleted.

    Las instrucciones de triggers DML utilizan dos tablas especiales denominadas inserted y deleted. SQL Server 2005 crea y administra automáticamente ambas tablas. La estructura de las tablas inserted y deleted es la misma que tiene la tabla que ha desencadenado la ejecución del trigger.

    La primera tabla (inserted) solo está disponible en las operaciones INSERT y UPDATE y en ella están los valores resultantes despues de la inserción o actualización. Es decir, los datos insertados. Inserted estará vacia en una operación DELETE.

    En la segunda (deleted), disponible en las operaciones UPDATE y DELETE, están los valores anteriores a la ejecución de la actualización o borrado. Es decir, los datos que serán borrados. Deleted estará vacia en una operacion INSERT.

    ¿No existe una tabla UPDATED? No, hacer una actualización es lo mismo que borrar (deleted) e insertar los nuevos (inserted). La sentencia UPDATE es la única en la que inserted y deleted tienen datos simultaneamente.

    No puede se modificar directamente los datos de estas tablas.

    El siguiente ejemplo, graba un historico de saldos cada vez que se modifica un saldo de la tabla cuentas.


CREATE TRIGGER TR_CUENTAS

ON CUENTAS

AFTER UPDATE

AS

BEGIN

-- SET NOCOUNT ON impide que se generen mensajes de texto

-- con cada instrucción

SET NOCOUNT ON;

INSERT INTO HCO_SALDOS

(IDCUENTA, SALDO, FXSALDO)

SELECT IDCUENTA, SALDO, getdate()

FROM INSERTED

END

    La siguiente instrucción provocará que el trigger se ejecute:


UPDATE CUENTAS

SET SALDO = SALDO + 10

WHERE IDCUENTA = 1

    Una consideración a tener en cuenta es que el trigger se ejecutará aunque la instruccion DML (UPDATE, INSERT o DELETE ) no haya afectado a ninguna fila. En este caso inserted y deleted devolveran un conjunto de datos vacio.

    Podemos especificar a que columnas de la tabla debe afectar el trigger.


ALTER TRIGGER TR_CUENTAS

ON CUENTAS

AFTER UPDATE

AS

BEGIN

-- SET NOCOUNT ON impide que se generen mensajes de texto

-- con cada instrucción

SET NOCOUNT ON;



IF UPDATE(SALDO) -- Solo si se actualiza SALDO

BEGIN

INSERT INTO HCO_SALDOS

(IDCUENTA, SALDO, FXSALDO)

SELECT IDCUENTA, SALDO, getdate()

FROM INSERTED

END

END

    Los trigger están dentro de la transacción original (Insert, Delete o Update) por lo cual si dentro de nuestro trigger hacemos un RollBack Tran, no solo estaremos echando atrás nuestro trigger sino también toda la transacción; en otras palabras si en un trigger ponemos un RollBack Tran, la transacción de Insert, Delete o Update volverá toda hacia atrás.


ALTER TRIGGER TR_CUENTAS

ON CUENTAS

AFTER UPDATE

AS

BEGIN

-- SET NOCOUNT ON impide que se generen mensajes de texto

-- con cada instrucción

SET NOCOUNT ON;

INSERT INTO HCO_SALDOS

(IDCUENTA, SALDO, FXSALDO)

SELECT IDCUENTA, SALDO, getdate()

FROM INSERTED



ROLLBACK

END

    En este caso obtendremos el siguiente mensaje de error:

La transacción terminó en el desencadenador. Se anuló el lote.

    Podemos activar y desactivar Triggers a tarvés de las siguientes instrucciones.



-- Desactiva el trigger TR_CUENTAS

DISABLE TRIGGER TR_CUENTAS ON CUENTAS

GO

-- activa el trigger TR_CUENTAS

ENABLE TRIGGER TR_CUENTAS ON CUENTAS

GO

-- Desactiva todos los trigger de la tabla CUENTAS

ALTER TABLE CUENTAS DISABLE TRIGGER ALL

GO

-- Activa todos los trigger de la tabla CUENTAS

ALTER TABLE CUENTAS ENABLE TRIGGER ALL


Trigger DDL

    Los trigger DDL se ejecutan en respuesta a una variedad de eventos de lenguaje de definición de datos (DDL). Estos eventos corresponden principalmente a instrucciones CREATE, ALTER y DROP de Transact-SQL, y a determinados procedimientos almacenados del sistema que ejecutan operaciones de tipo DDL.

    La sintaxis general de un trigger es la siguiente.


CREATE TRIGGER <trigger_name, sysname, table_alter_drop_safety>

ON DATABASE

FOR <data_definition_statements, , DROP_TABLE, ALTER_TABLE>

AS

BEGIN

...



END
    La siguiente instrucción impide que se ejecuten sentencias DROP TABLE y ALTER TABLE en la base de datos.


CREATE TRIGGER TR_SEGURIDAD

ON DATABASE FOR DROP_TABLE, ALTER_TABLE

AS

BEGIN

RAISERROR ('No está permitido borrar ni modificar tablas !' , 16, 1)

ROLLBACK TRANSACTION

END


impide que se ejecuten sentencias DROP TABLE y ALTER TABLE en la base de datos



CREATE TRIGGER TR_SEGURIDAD

ON DATABASE FOR DROP_TABLE, ALTER_TABLE

AS

BEGIN

RAISERROR ('No está permitido borrar ni modificar tablas !' , 16, 1)
ROLLBACK TRANSACTION

END

viernes, 25 de mayo de 2012

error servlet api cannot be found in classpath genexus

Tengo 2 environments 1 Web y otro Win

error servlet api cannot be found in classpath genexus

falta el servlet-api.jar en el classpath

C:\Archivos de programa\Apache Software Foundation\Tomcat 5.5\common\lib\servlet-api.jar

SQL Server Error : Network error IOException: Connection refused: connect




Error   : Network error IOException: Connection refused: connect


1) Desde el grupo de programas de SQL Server 2005 ejecutar el SQL Server 
Configuration Manager. 
Ir a Protocols for SQL Express y habilitar el acceso TCP/IP 
También hay que habilitar TCP/IP bajo SQL Client Native 
Configuration/Client Protocols 
2) Bajo Protocols for SQL Express, entrar a las propiedades de TCP/IP e ir 
al tab "IP Addresses"; al final de esa ventana está un grupo que dice IP 
ALL. Ahí hay que configurar: 
TCP Dinamic Ports = aquí hay que dejarlo vacío/en blanco 
TCP Port = 1433 
3) Reiniciar el Servicio del SQL Server 2005 Express 
4) Luego de eso pude hacer la REORG, de todas formas se recomienda tener 
configurado en el modelo el puerto 1433 y asegurarse que no haya otro 
server escuchando en ese mismo puerto (por ejemplo SQL Server 2000). 

jueves, 1 de marzo de 2012

SQL Ejecutar EXE xp_cmdshell


EXEC xp_cmdshell 'dir *.exe';

Para habilitar la ejecución se debe ejecutar:


---- To allow advanced options to be changed.
EXEC sp_configure 'show advanced options', 1
GO
--To update the currently configured value for advanced options.
RECONFIGURE
GO
-- To enable the feature.
EXEC sp_configure 'xp_cmdshell', 1
GO
--To update the currently configured value for this feature.
RECONFIGURE
GO

miércoles, 1 de febrero de 2012

Bloquear Teclado Mouse

En Visual Fox 6


Thisform.AddProperty('valor',0)
Declare Long BlockInput In "user32" Integer nOpcion
BlockInput(1)

con CTRL+ALT+DEL y luego cancelar volves a tener la posibilidad de ingresar por teclado


*
** FUNCTION DesactivarTeclasWindows(tlEstado)
** Funcion para Desactivar las Teclas CRTL + ALT + SUPR de Windows
*
** Parametros
**    tlEstado   =  Estado de las Teclas  (VALOR LOGICO)
**          .T.  = Desactiva las Teclas
**          .F.  = Activa las Teclas
*
*** Rutina suministrada por: ROD       -  eendor@hotmail.com
*** Ultima Modificacion:     Foxperto  -  foxperto@yahoo.com
***                          Marzo 01 2002
*
**************************************************************************
*
FUNCTION DesactivarTeclasWindows(tlEstado)

DECLARE INTEGER SystemParametersInfo IN USER32.DLL ;
LONG uAction, ;
LONG uParam, ;
STRING lpvParam, ;
LONG fuWinIni

uAction = 97
lpvParam = '0'
fuWinIni = 0

If tlEstado = .T.
*--- deshabilita las teclas
uParam = 1
tnResultado = SystemParametersInfo(@uAction,@uParam,lpvParam,@fuWinIni)
 Else
*--- habilita las teclas
uParam = 0
tnResultado = SystemParametersInfo(@uAction,@uParam,lpvParam,@fuWinIni)
EndIf

RETURN tnResultado

ENDFUNC
*
** Fin DesactivarTeclasWindows()
*

viernes, 27 de enero de 2012

SQL Se puede detectado interbloqueo al utilizar la sugerencia UPDLOCK

The SELECT/UPDATE problem, or, why UPDLOCK?

Ian's been having some deadlock trouble with SQL Server at work. I tried, but failed, to explain that two server processes running the same stored procedure could deadlock.
The problem comes when you need to update some rows in a table, but only when certain other data in each row is set. You can often do this simply by using the WHERE clause in the UPDATE statement, but if you need to set different values depending on the current values, or you need to update multiple tables simultaneously, it becomes more complicated. So we use a SELECT to get the current values and an UPDATE to write the new values, if we choose to.
The first thing to do is to ensure that we only write back if the data hasn't been changed. In SQL, each statement is atomic - either all of its effects are applied, or none are. However, here we need two statements, so we wrap them up in a transaction:
BEGIN TRAN
SELECT
   @value = Col1
FROM Tbl
WHERE
   RowID = @rowID

UPDATE Tbl
SET Col1 = @newValue
WHERE RowID = @rowID

-- Note, should check @@ERROR and ROLLBACK TRAN
-- if the update failed
COMMIT TRAN
Looks fine, right? Not always. Now I need to explain how SQL Server locks work.
Like all concurrent systems, SQL Server typically has more clients than available resources. It has to give an illusion of concurrent operations. The really, really hard way to allow transactions to operate simultaneously is to allocate new resources for every possibly-contending operation and reconcile them at the end of any atomic operation. The easy way is to lock the object to prevent contending operations, then release the lock at the end of the atomic operations. Locking reduces concurrency, but encourages correctness in a simple fashion.
SQL Server uses locking for concurrency. This is fine so long as locks aren't held for a long period of time. Reading a row takes a shared lock until the end of the atomic operation; updating a row takes an exclusive lock. If a shared lock is held, any other process can take a shared lock; a process wanting an exclusive lock must wait. If an exclusive lock is held, all other processes wanting a lock must wait.
With our query above, the SELECT takes a shared lock and holds it; the UPDATE escalates the shared lock to an exclusive lock.
Now, what happens if we run this query on another connection? Let's say we have queries Q1 and Q2, and to simplify things, let's assume that the server has a single processor. If the scheduler decides to run Q1, and is then interrupted to execute Q2, the following could happen: the SELECT from Q1 runs and takes a shared lock. Then, the SELECT from Q2 runs and takes another shared lock. Now Q2 is interrupted and the scheduler runs Q1 again, which tries to take an exclusive lock, which is blocked by Q2's shared lock. Q1 blocks so the scheduler runs Q2, which tries to take an exclusive lock to do an UPDATE, but is blocked by Q1's shared lock. Result: deadlock - neither Q1 nor Q2 can progress because they're both waiting for the other to finish.
You could give SQL Server a lock hint to take an exclusive lock instead of a shared lock when executing the SELECT, by specifying (XLOCK) after the table name. This stops the deadlock, because both will now try to acquire the exclusive lock, which means one must wait for the other. This has the nasty side-effect of preventing anyone else who just wanted to read the data from reading until we decide to update.
For this reason, SQL Server has another lock type: an update lock. The rules for this lock are simple. If no lock is held, or only shared locks are held, the update lock can be taken. Only one process can have an update lock, but other processes can take shared locks while an update lock is held. If the process holding the update lock wants to write, it is upgraded to an exclusive lock. So if we add the update lock hint (UPDLOCK) to our SELECT, Q1 and Q2 will now perform atomically, one after another, without deadlocking, while other processes can read the selected rows (at least, until we UPDATE).
BEGIN TRAN
SELECT
   @value = Col1
FROM Tbl (UPDLOCK)
WHERE
   RowID = @rowID

UPDATE Tbl
SET Col1 = @newValue
WHERE RowID = @rowID

-- Note, should check @@ERROR and ROLLBACK TRAN
-- if the update failed
COMMIT TRAN



Puede ejecutar en un interbloqueo al utilizar la sugerencia UPDLOCK. Considere el ejemplo siguiente:

El usuario A inicia la transacción siguiente:

   BEGIN TRAN
   SELECT COL1
         FROM TAB1(UPDLOCK)
         WHERE COL1 = 1
    

A continuación, el usuario B inicia otra transacción con los mismos comandos (esta operación se bloqueará por usuario):

   BEGIN TRAN
   SELECT COL1
         FROM TAB1(UPDLOCK)
         WHERE COL1 = 1
    

Ahora, si el usuario emite la siguiente UPDATE dentro de la misma transacción

   UPDATE TAB1
      SET   COL1 = 0
      WHERE COL1 = 1
    

Si no hay ningún índice para TAB1, se producirá el siguiente error:
Msj 1205, nivel 13, estado 2
El comando de servidor (id. de proceso 11) quedó interbloqueo con otro proceso
y fue elegida como sujeto del interbloqueo. Vuelva a ejecutar el comando.
Causa
El mismo bloqueo de actualización se promueve a un bloqueo de tabla cuando no ha...
El mismo bloqueo de actualización se promueve a un bloqueo de tabla cuando no hay ningún índice para una tabla. O bien, cuando la instrucción UPDATE es no restringida, un bloqueo Update_page anterior se promueve a un tipo de bloqueo Ex_table. Si otra transacción ya coloca un bloqueo Ex_intent en la misma tabla, la extensión de bloqueo no se puede tener éxito y se detecta el interbloqueo.

Solución
Para evitar este problema, siga uno de los siguientes: Crear un índice en TAB1....

Para evitar este problema, siga uno de los siguientes:
  • Crear un índice en TAB1.

    -o bien -
  • Agregue una cláusula WHERE a la instrucción UPDATE si ya tiene un índice en la tabla.

Más información
Para obtener más información, vea el artículo siguiente en Microsoft Knowledge B...

Para obtener más información, vea el artículo siguiente en Microsoft Knowledge Base:
169960  (http://support.microsoft.com/kb/169960/EN-US/ ) : INF: analizar y evitar los interbloqueos en SQL Server