Vengo escribiendo código desde hace 33 años, tengo empresa y esto le enseño a todos los desarrolladores que he instruido.
Tips, código fuente, ayudas y orientaciones en código y herramientas de programación... tan solo para ahorrar un poco de tiempo luego de las largas horas que luché en encontrar estas soluciones. :) #Traveler #Developer #ArtificialIntelligence #AI #DeepLearning #InteligenciaArtificial #Criptomonedas #Cryptocurrency #Blockchain
Mostrando entradas con la etiqueta Mensajes de error. Mostrar todas las entradas
Mostrando entradas con la etiqueta Mensajes de error. Mostrar todas las entradas
viernes, 10 de noviembre de 2017
Cómo ser un Freelancer en programación y no morir en el intento.
domingo, 10 de abril de 2016
[Corregido] Error al crear Ordenes de compra, Facturas, Presupuestos y Ordenes de venta luego de migración en VTiger
Luego de una migración en vTiger, uno espera no tener ningun problema. Aún así, nos piden que hagamos backup para estar preparados para nuestros inmerecidos y muy probables problemas de migración.
Listo. Backup de código y base de datos creados. Y comenzamos la migración de vTiger.
Una vez terminados, nos hemos topado con algunos mensajes de advertencia de pequeñas ejecuciones en la base de datos que no se pudieron completar satisfactoriamente, y aunque reintentamos la migración siguen saliendo. Optamos por no prestarle atención y correr a ejecutar nuestra nueva versión de vTiger.
Aunque ya activamos el "log" y "trace" para validar el error, nos encontramos con que es imposible crear una nueva Orden de Compra, Factura, Presupuesto u Orden de compra, y siempre nos aparece el mensaje de:
...o en español:
No hay nada que temer... pueden consultar durante 2 días, tal como yo lo hice en todos los foros, y seguir cada paso y no encontrar ninguna solución en el universo indexado de Internet... o simplemente vayan directamente en la base de datos y hagan los siguientes dos cambios:
Para Facturas:
Para Presupuestos:
Para Ordens de compra:
La solución es, simplemente, eliminar el registro duplicado que aparece en cada consulta, y dejar uno de ellos (por ejemplo, he dejado el primero):
Y listo. vTiger vuelve a ser tan eficiente como antes.
Requiere ayuda en su nuevo CRM? Podemos ayudarle en Solutecia sas.
Listo. Backup de código y base de datos creados. Y comenzamos la migración de vTiger.
Una vez terminados, nos hemos topado con algunos mensajes de advertencia de pequeñas ejecuciones en la base de datos que no se pudieron completar satisfactoriamente, y aunque reintentamos la migración siguen saliendo. Optamos por no prestarle atención y correr a ejecutar nuestra nueva versión de vTiger.
Aunque ya activamos el "log" y "trace" para validar el error, nos encontramos con que es imposible crear una nueva Orden de Compra, Factura, Presupuesto u Orden de compra, y siempre nos aparece el mensaje de:
{"success":false,"error":{"code":"result is not an object","message":"result is not an object"}}
...o en español:
{"success":false,"error":{"code":"El registro al que pretende acceder no existe","message":"El registro al que pretende acceder no existe"}}
No hay nada que temer... pueden consultar durante 2 días, tal como yo lo hice en todos los foros, y seguir cada paso y no encontrar ninguna solución en el universo indexado de Internet... o simplemente vayan directamente en la base de datos y hagan los siguientes dos cambios:
1) En la estructura de la tabla "vtiger_users"
En la estructura de la tabla, asegurarse que existe el campo "is_owner", y debe ser "varchar(5).2) En los registros la tabla "vtiger_field"
Revisar los registros de los 4 módulos que nos están generando problemas, con las siguientes consultas:Para Facturas:
SELECT * FROM vtiger_field WHERE tablename = 'vtiger_invoice' ORDER BY columnname
Para Ordenes de ventaSELECT * FROM vtiger_field WHERE tablename = 'vtiger_salesorder' ORDER BY columnnamePara Presupuestos:
SELECT * FROM vtiger_field WHERE tablename = 'vtiger_quotes' ORDER BY columnnamePara Ordens de compra:
SELECT * FROM vtiger_field WHERE tablename = 'vtiger_purchaseorder' ORDER BY columnnameLa solución es, simplemente, eliminar el registro duplicado que aparece en cada consulta, y dejar uno de ellos (por ejemplo, he dejado el primero):
Y listo. vTiger vuelve a ser tan eficiente como antes.
Requiere ayuda en su nuevo CRM? Podemos ayudarle en Solutecia sas.
jueves, 7 de abril de 2016
[Corregido] Call to a member function getPicklistValues() on a non-object in /crm/modules/Users/models/Record.php on line 494
Acabo de encontrarme con este mensaje de error luego de una migración de VTiger de 5.4 a 6.1.
En el foro de VTiger no han dado con una solución satisfactoria, y por algún motivo no tengo privilegios para postear la solución en dicho foro.
Bueno, aquí con la solución.
El problema lo podemos resolver directamente en el archivo ubicado en la ruta:
modules/Users/models/Record.php
Inicialmente, aparece esta código al rededor de la línea 494:
//-----------------------------------------------------------------------------
$hour_format = $fieldModel['hour_format']->getPicklistValues();
$start_hour = $fieldModel['start_hour']->getPicklistValues();
$defaultValues = array('00:00'=>'12:00 AM','01:00'=>'01:00 AM','02:00'=>'02:00 AM','03:00'=>'03:00 AM','04:00'=>'04:00 AM','05:00'=>'05:00 AM',
'06:00'=>'06:00 AM','07:00'=>'07:00 AM','08:00'=>'08:00 AM','09:00'=>'09:00 AM','10:00'=>'10:00 AM','11:00'=>'11:00 AM','12:00'=>'12:00 PM',
'13:00'=>'01:00 PM','14:00'=>'02:00 PM','15:00'=>'03:00 PM','16:00'=>'04:00 PM','17:00'=>'05:00 PM','18:00'=>'06:00 PM','19:00'=>'07:00 PM',
'20:00'=>'08:00 PM','21:00'=>'09:00 PM','22:00'=>'10:00 PM','23:00'=>'11:00 PM');
//-----------------------------------------------------------------------------
Por algún motivo luego de la migración, no toma el listado por defecto de los Picklist para el listado de los horarios, pero si incluye los valores por defecto una línea más abajo.
Parece algo poco lógico, que hayan colocado los valores por defecto luego, yo simplemente le di el orden que me pareció más acertado. Por lo tanto lo dejé de la siguiente manera:
//-----------------------------------------------------------------------------
$defaultValues = array('00:00'=>'12:00 AM','01:00'=>'01:00 AM','02:00'=>'02:00 AM','03:00'=>'03:00 AM','04:00'=>'04:00 AM','05:00'=>'05:00 AM',
'06:00'=>'06:00 AM','07:00'=>'07:00 AM','08:00'=>'08:00 AM','09:00'=>'09:00 AM','10:00'=>'10:00 AM','11:00'=>'11:00 AM','12:00'=>'12:00 PM',
'13:00'=>'01:00 PM','14:00'=>'02:00 PM','15:00'=>'03:00 PM','16:00'=>'04:00 PM','17:00'=>'05:00 PM','18:00'=>'06:00 PM','19:00'=>'07:00 PM',
'20:00'=>'08:00 PM','21:00'=>'09:00 PM','22:00'=>'10:00 PM','23:00'=>'11:00 PM');
$hour_format = $defaultValues;
$start_hour = $defaultValues;
//-----------------------------------------------------------------------------
Y tema solucionado.
En el foro de VTiger no han dado con una solución satisfactoria, y por algún motivo no tengo privilegios para postear la solución en dicho foro.
Bueno, aquí con la solución.
El problema lo podemos resolver directamente en el archivo ubicado en la ruta:
modules/Users/models/Record.php
Inicialmente, aparece esta código al rededor de la línea 494:
//-----------------------------------------------------------------------------
$hour_format = $fieldModel['hour_format']->getPicklistValues();
$start_hour = $fieldModel['start_hour']->getPicklistValues();
$defaultValues = array('00:00'=>'12:00 AM','01:00'=>'01:00 AM','02:00'=>'02:00 AM','03:00'=>'03:00 AM','04:00'=>'04:00 AM','05:00'=>'05:00 AM',
'06:00'=>'06:00 AM','07:00'=>'07:00 AM','08:00'=>'08:00 AM','09:00'=>'09:00 AM','10:00'=>'10:00 AM','11:00'=>'11:00 AM','12:00'=>'12:00 PM',
'13:00'=>'01:00 PM','14:00'=>'02:00 PM','15:00'=>'03:00 PM','16:00'=>'04:00 PM','17:00'=>'05:00 PM','18:00'=>'06:00 PM','19:00'=>'07:00 PM',
'20:00'=>'08:00 PM','21:00'=>'09:00 PM','22:00'=>'10:00 PM','23:00'=>'11:00 PM');
//-----------------------------------------------------------------------------
Por algún motivo luego de la migración, no toma el listado por defecto de los Picklist para el listado de los horarios, pero si incluye los valores por defecto una línea más abajo.
Parece algo poco lógico, que hayan colocado los valores por defecto luego, yo simplemente le di el orden que me pareció más acertado. Por lo tanto lo dejé de la siguiente manera:
//-----------------------------------------------------------------------------
$defaultValues = array('00:00'=>'12:00 AM','01:00'=>'01:00 AM','02:00'=>'02:00 AM','03:00'=>'03:00 AM','04:00'=>'04:00 AM','05:00'=>'05:00 AM',
'06:00'=>'06:00 AM','07:00'=>'07:00 AM','08:00'=>'08:00 AM','09:00'=>'09:00 AM','10:00'=>'10:00 AM','11:00'=>'11:00 AM','12:00'=>'12:00 PM',
'13:00'=>'01:00 PM','14:00'=>'02:00 PM','15:00'=>'03:00 PM','16:00'=>'04:00 PM','17:00'=>'05:00 PM','18:00'=>'06:00 PM','19:00'=>'07:00 PM',
'20:00'=>'08:00 PM','21:00'=>'09:00 PM','22:00'=>'10:00 PM','23:00'=>'11:00 PM');
$hour_format = $defaultValues;
$start_hour = $defaultValues;
//-----------------------------------------------------------------------------
Y tema solucionado.
lunes, 20 de abril de 2015
[Corregido] The term ‘Add-SPSolution ’ is not recognized as the name of a cmdlet, function, script file, or operable program.
1. Identificando el problema.
Intentando hacer una instalación de un WebPart en SharePoint 2010, en una nueva máquina, me topé con el siguiente error, ejecutando en la consola de administración:
The term ‘Add-SPSolution ’ is not recognized as the name of a cmdlet, function, script file, or operable program.
Me imaginaba que al estar instalado Powershell en producción, interpretaría los comandos de SharePoint.Powershell automáticamente, pero no era así.
2. Solución.
Luego de buscar mucho en la WEB, me topé con una solución algo absurda, pero me funcionó:
Antes de ejecutar el script en Powershell, es necesario incluir una primera linea de comando, donde se le indique a la máquina que habilite el Powershell ISE.
Agreguen la siguiente linea al comienzo del scrit que están corriendo:
Add-PSSnapin Microsoft.Sharepoint.Powershell –EA 0
Pero para una solución a largo plazo, esto puede ser desgastante. Entonces les recomiendo leer el siguiente artículo:
http://blogs.msdn.com/b/kaevans/archive/2011/11/14/add-microsoft-sharepoint-powershell-snap-in-to-all-powershell-windows.aspx
miércoles, 8 de octubre de 2014
Resolviendo: ‘An exception occurred in publishing: No such interface supported (Exception from HRESULT: 0×80004002 (E_NOINTERFACE)’
Así que estoy utilizando Visual Studio 2010 RC (también lo vi rompiendo mi paciencia en Visual Studio 2012) y es un placer usarlo como una forma sencilla de publicar mis proyectos a diferentes ambientes. Sin embargo, un problema surgió hoy después de instalar algunas actualizaciones de herramientas web:
"Se produjo una excepción en la publicación: No se admite esa interfaz (Excepción de HRESULT: 0×80004002 (E_NOINTERFACE)"
Ni siquiera podía abrir la configuración de publicación de diálogo para ver si algo estaba mal en ese país. Traté de reiniciar Visual Studio, luego ejecutarlo como administrador, no hay cambio. Al final encontré los siguientes pasos en un foro que se resolvió el problema para mí:
Espero que esto sea de utilidad para alguien más por ahí golpeando su cabeza contra una pared de ladrillos tratando la forma de resolverlo.
"Se produjo una excepción en la publicación: No se admite esa interfaz (Excepción de HRESULT: 0×80004002 (E_NOINTERFACE)"
Ni siquiera podía abrir la configuración de publicación de diálogo para ver si algo estaba mal en ese país. Traté de reiniciar Visual Studio, luego ejecutarlo como administrador, no hay cambio. Al final encontré los siguientes pasos en un foro que se resolvió el problema para mí:
- Ejecuté el símbolo del sistema como administrador
- regsvr32 actxprxy.dll
- Reinicie Visual Studio
Espero que esto sea de utilidad para alguien más por ahí golpeando su cabeza contra una pared de ladrillos tratando la forma de resolverlo.
jueves, 14 de agosto de 2014
No se puede insertar el valor NULL en la columna 'cualquiera', tabla 'bd.esquema.tabla'. La columna no admite valores NULL. Error de INSERT. Se terminó la instrucción.
Volvemos a las migraciones entre servidores... éste es a veces un problema que se nos presenta cuando ya hemos hecho casi de todo y creíamos que nuestra base de datos quedó bien respaldada y bien montada.
...pues no. No quedó bien respaldada y mucho menos bien montada. Y nos damos totazos contra la pared porque ya no hay marcha atrás y no tenemos acceso al servidor original. ¿Qué hacer?
Primero que todo alejemos al cliente un ratico a que se tome un café para que no nos respire en el cuello y nos remangamos la camisa... esto es lo que hay que hacer:
Sucede que al respaldar la base de datos de nuestro proyecto, no incluimos sus propiedades extendidas, y al montarla, se perdieron los índices, claves principales y autonuméricos.
Esto puede ser un grave problema si no tienes a la mano un manual de la base de datos (o una formidable memoria), para recordar cuáles campos hay que volver a colocar los índices, claves principales y autonuméricos.
La buena noticia, es que hay solución. La mala, es que es tediosa. Hay que volver a asignarle los índices y autonuméricos a nuestras tablas de manera manual.
1) Valida que en el nuevo servidor si puedas hacer cambios en la base de datos. ¿Por qué? Es posible que te aparezca un mensaje al momento de guardar un índice que dice literalmente "No se permite guardar. Los cambios que ha realizado requieren que se quiten y vuelvan a crear las siguientes tablas. Quizá ha realizado cambios en una tabla que no se puede volver a crear o ha habilitado la opción Impedir guardar cambios que requieran volver a crear tablas".
El SQL Server Management Studio el viene con la opción "Impedir guardar cambios que requieran volver a crear tablas" habilitada de manera predeterminada, si olvida colocarle un campo, lo nombra mal o deja mal el tipo de dato esto evita que guarde las modificaciones. Para cambiar esto, simplemente ingresa en el SQL Server Management Studio por Herramientas -> Opciones y en la ventana busca al lado izquierdo del árbol la opción de "Diseñadores" deshabilita esta opción. Así como se ve en la imagen de ejemplo:
2) Acceder a las columnas en las tablas para modificarlas.
Entrar en el diseño de cada una de las tablas para modificarles sus propiedades. Esto lo haces simplemente con el botón derecho sobre cada tabla y pulsando la opción de "Diseño".
3) Asignar los índices principales en las columnas de las tablas.
Segun cada tipo de dato en tus tablas:
Como decía anteriormente, puede que no todo esté perdido, pero el no haber guardado bien un respaldo de base de datos, nos puede poner en un trabajo un poco más largo.
...pues no. No quedó bien respaldada y mucho menos bien montada. Y nos damos totazos contra la pared porque ya no hay marcha atrás y no tenemos acceso al servidor original. ¿Qué hacer?
Primero que todo alejemos al cliente un ratico a que se tome un café para que no nos respire en el cuello y nos remangamos la camisa... esto es lo que hay que hacer:
Entendiendo el problema
Sucede que al respaldar la base de datos de nuestro proyecto, no incluimos sus propiedades extendidas, y al montarla, se perdieron los índices, claves principales y autonuméricos.
Esto puede ser un grave problema si no tienes a la mano un manual de la base de datos (o una formidable memoria), para recordar cuáles campos hay que volver a colocar los índices, claves principales y autonuméricos.
Solucionando poco a poco
La buena noticia, es que hay solución. La mala, es que es tediosa. Hay que volver a asignarle los índices y autonuméricos a nuestras tablas de manera manual.
1) Valida que en el nuevo servidor si puedas hacer cambios en la base de datos. ¿Por qué? Es posible que te aparezca un mensaje al momento de guardar un índice que dice literalmente "No se permite guardar. Los cambios que ha realizado requieren que se quiten y vuelvan a crear las siguientes tablas. Quizá ha realizado cambios en una tabla que no se puede volver a crear o ha habilitado la opción Impedir guardar cambios que requieran volver a crear tablas".
El SQL Server Management Studio el viene con la opción "Impedir guardar cambios que requieran volver a crear tablas" habilitada de manera predeterminada, si olvida colocarle un campo, lo nombra mal o deja mal el tipo de dato esto evita que guarde las modificaciones. Para cambiar esto, simplemente ingresa en el SQL Server Management Studio por Herramientas -> Opciones y en la ventana busca al lado izquierdo del árbol la opción de "Diseñadores" deshabilita esta opción. Así como se ve en la imagen de ejemplo:
2) Acceder a las columnas en las tablas para modificarlas.
Entrar en el diseño de cada una de las tablas para modificarles sus propiedades. Esto lo haces simplemente con el botón derecho sobre cada tabla y pulsando la opción de "Diseño".
3) Asignar los índices principales en las columnas de las tablas.
Segun cada tipo de dato en tus tablas:
- Uniqueidentifier. 1) Seleccionar la columna del Indice principal. 2) Pulsar el botón de "Establecer clave principal". 3) En la propiedad de "Valor o enlace predeterminado" ponerle el valor de "NEWID()". 4) Guardar. De esta manera, queda lista la columna con llave principal y auto asignación de un nuevo valor:
- Int, Bigint. Aplica para los tipos de datos enteros y es muy similar al anterior. 1) Seleccionar la columna del Indice principal. 2) Pulsar el botón de "Establecer clave principal". 3) En la propiedad de "Especificación de Identidad" en el campo de (Identidad) ponerle el valor de "SI". 4) Guardar.
Como decía anteriormente, puede que no todo esté perdido, pero el no haber guardado bien un respaldo de base de datos, nos puede poner en un trabajo un poco más largo.
martes, 29 de julio de 2014
System.Data.OracleClient requires Oracle client software version 8.1.7 or greater.
En una reciente migración de un servidor, nos topamos con este mensaje de error, cuando nuestra aplicación de ASP.NET intentaba conectar con el servidor de base de datos de Oracle.
El mensaje cuando lanzaba cualquier consulta era el mismo:
System.Data.OracleClient requires Oracle client software version 8.1.7 or greater.
Existen dos posibilidades para este error.
Recordemos que estamos en una nueva máquina y que estamos tratando de acceder a la BD de Oracle desde nuestra aplicación de ASP.NET.
Las causas pueden ser dos muy diferentes:
Si se trata del primer caso, lo más seguro es que luego hay que atender también el segundo caso.
Los enlaces de descarga se pueden encontrar en:
http://www.oracle.com/technetwork/topics/dotnet/utilsoft-086879.html
Es necesario conocer muy bien la máquina y el sistema operativo que se tiene en el servidor para seleccionar el enlace adecuado.
El procedimiento es sencillo:
"Reiniciar la máquina."
Aquí no hay experiencia que valga... o se reinicia la máquina o todo lo mencionado en este artículo puede quedar en el papel con que vamos a limpiar los vídrios.
El mensaje cuando lanzaba cualquier consulta era el mismo:
System.Data.OracleClient requires Oracle client software version 8.1.7 or greater.
Existen dos posibilidades para este error.
Recordemos que estamos en una nueva máquina y que estamos tratando de acceder a la BD de Oracle desde nuestra aplicación de ASP.NET.
Las causas pueden ser dos muy diferentes:
- No se ha instalado el Microsoft OLE DB provider for Oracle.
- La carpeta de la instalación de Oracle no tiene permiso para el usuario de ASP.NET
Si se trata del primer caso, lo más seguro es que luego hay que atender también el segundo caso.
1. Instalar Microsoft OLE DB provider for Oracle.
Los enlaces de descarga se pueden encontrar en:
http://www.oracle.com/technetwork/topics/dotnet/utilsoft-086879.html
Es necesario conocer muy bien la máquina y el sistema operativo que se tiene en el servidor para seleccionar el enlace adecuado.
2. Dar permisos administrativos a la carpeta de Oracle
El procedimiento es sencillo:
- Dar permisos sobre la carpeta de Oracle a los usuarios “Authenticated Users” y “ASP.net”
- Loguearse a Windows con credenciales administrativas.
- Ir a la carpeta raíz de Oracle que generalmente se encuentra en: C:\Oracle.
- Ir a las propiedades de la carpeta y seleccionar la pestaña “Seguridad”.
- Click on “Authenticated Users” item in the “Name” list.
- Agregar los usuarios “Authenticated Users” y “ASP.net” y asignarles permisos de “Full Control”.
- Dar clic en el botón “Avanzado”, se eligen los usuarios mencionados anteriormente y se seleccionar las opciones “Permitir que los permisos heredables del primario se propaguen a este objeto y a todos los objetos secundarios. Incluirlos junto con las entradas indicadas aquí de forma explícita” y “Reemplazar las entradas de permisos en todos los objetos secundarios con aquellas entradas incluidas aquí y que sean relativas a los objetos secundarios”.
- Dar clic en OK y reiniciar el equipo para asegurarse de que los cambios surtan efecto.
NOTA IMPORTANTE
"Reiniciar la máquina."
Aquí no hay experiencia que valga... o se reinicia la máquina o todo lo mencionado en este artículo puede quedar en el papel con que vamos a limpiar los vídrios.
jueves, 24 de abril de 2014
Error con date_default_timezone_set() en PHP
El Error:
date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin*' for 'CEST/2.0/DST' instead.
*...o cualquier otro sitio de este hermoso planeta.
Se nos ha presentado este error una vez montado el proyecto en el servidor, y puede ser por varias causas:
Para darle solución a este detalle, primero que todo, supongamos que no se trata de la última causa. Entonces demos solución en el código de nuestro archivo de PHP.
Muy al comienzo, antes de hacer uso de cualquier función date(). Debemos indicarle al servidor cuál es nuestra zona horaria con la siguiente instrucción:
Solución en el código:
Solución en el archivo php.ini:
No importa si el servidor se encuentra físicamente en otro país, la coniguración que aquí indicamos va a determinar los resultados de las funciones de fecha y tiempo en nuestra aplicación.
Aquí les dejo el listado de opciones que he podido encontrar buscando en la red:
date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin*' for 'CEST/2.0/DST' instead.
*...o cualquier otro sitio de este hermoso planeta.
Se nos ha presentado este error una vez montado el proyecto en el servidor, y puede ser por varias causas:
- Nos han cambiado la versión de PHP. Es decir, han actualizado la versión de PHP a una superior a 5.1.
- No hemos incluido la linea de configuración de fecha en el servidor en nuestro código. Esto es necesario si no se maneja en el php.ini
- No hemos incluido la validación de la fecha y zona en nuestro php.ini
- El servidor se enloqueció de la noche a la mañana.
Para darle solución a este detalle, primero que todo, supongamos que no se trata de la última causa. Entonces demos solución en el código de nuestro archivo de PHP.
Muy al comienzo, antes de hacer uso de cualquier función date(). Debemos indicarle al servidor cuál es nuestra zona horaria con la siguiente instrucción:
Solución en el código:
<?php
date_default_timezone_set("America/Bogota"); //Configuramos el timezone
echo date_default_timezone_get(); // Vemos qué ha quedado configurado
//...de aqui en adelante el resto de nuestro código
?>
Solución en el archivo php.ini:
[Date]
; Defines the default timezone used by the date functions
date.timezone = America/Chicago
No importa si el servidor se encuentra físicamente en otro país, la coniguración que aquí indicamos va a determinar los resultados de las funciones de fecha y tiempo en nuestra aplicación.
Aquí les dejo el listado de opciones que he podido encontrar buscando en la red:
- Africa/Abidjan
- Africa/Accra
- Africa/Addis_Ababa
- Africa/Algiers
- Africa/Asmara
- Africa/Asmera
- Africa/Bamako
- Africa/Bangui
- Africa/Banjul
- Africa/Bissau
- Africa/Blantyre
- Africa/Brazzaville
- Africa/Bujumbura
- Africa/Cairo
- Africa/Casablanca
- Africa/Ceuta
- Africa/Conakry
- Africa/Dakar
- Africa/Dar_es_Salaam
- Africa/Djibouti
- Africa/Douala
- Africa/El_Aaiun
- Africa/Freetown
- Africa/Gaborone
- Africa/Harare
- Africa/Johannesburg
- Africa/Kampala
- Africa/Khartoum
- Africa/Kigali
- Africa/Kinshasa
- Africa/Lagos
- Africa/Libreville
- Africa/Lome
- Africa/Luanda
- Africa/Lubumbashi
- Africa/Lusaka
- Africa/Malabo
- Africa/Maputo
- Africa/Maseru
- Africa/Mbabane
- Africa/Mogadishu
- Africa/Monrovia
- Africa/Nairobi
- Africa/Ndjamena
- Africa/Niamey
- Africa/Nouakchott
- Africa/Ouagadougou
- Africa/Porto-Novo
- Africa/Sao_Tome
- Africa/Timbuktu
- Africa/Tripoli
- Africa/Tunis
- Africa/Windhoek
- America/Adak
- America/Anchorage
- America/Anguilla
- America/Antigua
- America/Araguaina
- America/Argentina/Buenos_Aires
- America/Argentina/Catamarca
- America/Argentina/ComodRivadavia
- America/Argentina/Cordoba
- America/Argentina/Jujuy
- America/Argentina/La_Rioja
- America/Argentina/Mendoza
- America/Argentina/Rio_Gallegos
- America/Argentina/San_Juan
- America/Argentina/Tucuman
- America/Argentina/Ushuaia
- America/Aruba
- America/Asuncion
- America/Atikokan
- America/Atka
- America/Bahia
- America/Barbados
- America/Belem
- America/Belize
- America/Blanc-Sablon
- America/Boa_Vista
- America/Bogota
- America/Boise
- America/Buenos_Aires
- America/Cambridge_Bay
- America/Campo_Grande
- America/Cancun
- America/Caracas
- America/Catamarca
- America/Cayenne
- America/Cayman
- America/Chicago
- America/Chihuahua
- America/Coral_Harbour
- America/Cordoba
- America/Costa_Rica
- America/Cuiaba
- America/Curacao
- America/Danmarkshavn
- America/Dawson
- America/Dawson_Creek
- America/Denver
- America/Detroit
- America/Dominica
- America/Edmonton
- America/Eirunepe
- America/El_Salvador
- America/Ensenada
- America/Fort_Wayne
- America/Fortaleza
- America/Glace_Bay
- America/Godthab
- America/Goose_Bay
- America/Grand_Turk
- America/Grenada
- America/Guadeloupe
- America/Guatemala
- America/Guayaquil
- America/Guyana
- America/Halifax
- America/Havana
- America/Hermosillo
- America/Indiana/Indianapolis
- America/Indiana/Knox
- America/Indiana/Marengo
- America/Indiana/Petersburg
- America/Indiana/Vevay
- America/Indiana/Vincennes
- America/Indiana/Winamac
- America/Indianapolis
- America/Inuvik
- America/Iqaluit
- America/Jamaica
- America/Jujuy
- America/Juneau
- America/Kentucky/Louisville
- America/Kentucky/Monticello
- America/Knox_IN
- America/La_Paz
- America/Lima
- America/Los_Angeles
- America/Louisville
- America/Maceio
- America/Managua
- America/Manaus
- America/Martinique
- America/Mazatlan
- America/Mendoza
- America/Menominee
- America/Merida
- America/Mexico_City
- America/Miquelon
- America/Moncton
- America/Monterrey
- America/Montevideo
- America/Montreal
- America/Montserrat
- America/Nassau
- America/New_York
- America/Nipigon
- America/Nome
- America/Noronha
- America/North_Dakota/Center
- America/North_Dakota/New_Salem
- America/Panama
- America/Pangnirtung
- America/Paramaribo
- America/Phoenix
- America/Port-au-Prince
- America/Port_of_Spain
- America/Porto_Acre
- America/Porto_Velho
- America/Puerto_Rico
- America/Rainy_River
- America/Rankin_Inlet
- America/Recife
- America/Regina
- America/Resolute
- America/Rio_Branco
- America/Rosario
- America/Santiago
- America/Santo_Domingo
- America/Sao_Paulo
- America/Scoresbysund
- America/Shiprock
- America/St_Johns
- America/St_Kitts
- America/St_Lucia
- America/St_Thomas
- America/St_Vincent
- America/Swift_Current
- America/Tegucigalpa
- America/Thule
- America/Thunder_Bay
- America/Tijuana
- America/Toronto
- America/Tortola
- America/Vancouver
- America/Virgin
- America/Whitehorse
- America/Winnipeg
- America/Yakutat
- America/Yellowknife
- Antarctica/Casey
- Antarctica/Davis
- Antarctica/DumontDUrville
- Antarctica/Mawson
- Antarctica/McMurdo
- Antarctica/Palmer
- Antarctica/Rothera
- Antarctica/South_Pole
- Antarctica/Syowa
- Antarctica/Vostok
- Arctic/Longyearbyen
- Asia/Aden
- Asia/Almaty
- Asia/Amman
- Asia/Anadyr
- Asia/Aqtau
- Asia/Aqtobe
- Asia/Ashgabat
- Asia/Ashkhabad
- Asia/Baghdad
- Asia/Bahrain
- Asia/Baku
- Asia/Bangkok
- Asia/Beirut
- Asia/Bishkek
- Asia/Brunei
- Asia/Calcutta
- Asia/Choibalsan
- Asia/Chongqing
- Asia/Chungking
- Asia/Colombo
- Asia/Dacca
- Asia/Damascus
- Asia/Dhaka
- Asia/Dili
- Asia/Dubai
- Asia/Dushanbe
- Asia/Gaza
- Asia/Harbin
- Asia/Hong_Kong
- Asia/Hovd
- Asia/Irkutsk
- Asia/Istanbul
- Asia/Jakarta
- Asia/Jayapura
- Asia/Jerusalem
- Asia/Kabul
- Asia/Kamchatka
- Asia/Karachi
- Asia/Kashgar
- Asia/Katmandu
- Asia/Krasnoyarsk
- Asia/Kuala_Lumpur
- Asia/Kuching
- Asia/Kuwait
- Asia/Macao
- Asia/Macau
- Asia/Magadan
- Asia/Makassar
- Asia/Manila
- Asia/Muscat
- Asia/Nicosia
- Asia/Novosibirsk
- Asia/Omsk
- Asia/Oral
- Asia/Phnom_Penh
- Asia/Pontianak
- Asia/Pyongyang
- Asia/Qatar
- Asia/Qyzylorda
- Asia/Rangoon
- Asia/Riyadh
- Asia/Riyadh87
- Asia/Riyadh88
- Asia/Riyadh89
- Asia/Saigon
- Asia/Sakhalin
- Asia/Samarkand
- Asia/Seoul
- Asia/Shanghai
- Asia/Singapore
- Asia/Taipei
- Asia/Tashkent
- Asia/Tbilisi
- Asia/Tehran
- Asia/Tel_Aviv
- Asia/Thimbu
- Asia/Thimphu
- Asia/Tokyo
- Asia/Ujung_Pandang
- Asia/Ulaanbaatar
- Asia/Ulan_Bator
- Asia/Urumqi
- Asia/Vientiane
- Asia/Vladivostok
- Asia/Yakutsk
- Asia/Yekaterinburg
- Asia/Yerevan
- Atlantic/Azores
- Atlantic/Bermuda
- Atlantic/Canary
- Atlantic/Cape_Verde
- Atlantic/Faeroe
- Atlantic/Faroe
- Atlantic/Jan_Mayen
- Atlantic/Madeira
- Atlantic/Reykjavik
- Atlantic/South_Georgia
- Atlantic/St_Helena
- Atlantic/Stanley
- Australia/ACT
- Australia/Adelaide
- Australia/Brisbane
- Australia/Broken_Hill
- Australia/Canberra
- Australia/Currie
- Australia/Darwin
- Australia/Eucla
- Australia/Hobart
- Australia/LHI
- Australia/Lindeman
- Australia/Lord_Howe
- Australia/Melbourne
- Australia/NSW
- Australia/North
- Australia/Perth
- Australia/Queensland
- Australia/South
- Australia/Sydney
- Australia/Tasmania
- Australia/Victoria
- Australia/West
- Australia/Yancowinna
- Brazil/Acre
- Brazil/DeNoronha
- Brazil/East
- Brazil/West
- CET
- CST6CDT
- Canada/Atlantic
- Canada/Central
- Canada/East-Saskatchewan
- Canada/Eastern
- Canada/Mountain
- Canada/Newfoundland
- Canada/Pacific
- Canada/Saskatchewan
- Canada/Yukon
- Chile/Continental
- Chile/EasterIsland
- Cuba
- EET
- EST
- EST5EDT
- Egypt
- Eire
- Etc/GMT
- Etc/GMT+0
- Etc/GMT+1
- Etc/GMT+10
- Etc/GMT+11
- Etc/GMT+12
- Etc/GMT+2
- Etc/GMT+3
- Etc/GMT+4
- Etc/GMT+5
- Etc/GMT+6
- Etc/GMT+7
- Etc/GMT+8
- Etc/GMT+9
- Etc/GMT-0
- Etc/GMT-1
- Etc/GMT-10
- Etc/GMT-11
- Etc/GMT-12
- Etc/GMT-13
- Etc/GMT-14
- Etc/GMT-2
- Etc/GMT-3
- Etc/GMT-4
- Etc/GMT-5
- Etc/GMT-6
- Etc/GMT-7
- Etc/GMT-8
- Etc/GMT-9
- Etc/GMT0
- Etc/Greenwich
- Etc/UCT
- Etc/UTC
- Etc/Universal
- Etc/Zulu
- Europe/Amsterdam
- Europe/Andorra
- Europe/Athens
- Europe/Belfast
- Europe/Belgrade
- Europe/Berlin
- Europe/Bratislava
- Europe/Brussels
- Europe/Bucharest
- Europe/Budapest
- Europe/Chisinau
- Europe/Copenhagen
- Europe/Dublin
- Europe/Gibraltar
- Europe/Guernsey
- Europe/Helsinki
- Europe/Isle_of_Man
- Europe/Istanbul
- Europe/Jersey
- Europe/Kaliningrad
- Europe/Kiev
- Europe/Lisbon
- Europe/Ljubljana
- Europe/London
- Europe/Luxembourg
- Europe/Madrid
- Europe/Malta
- Europe/Mariehamn
- Europe/Minsk
- Europe/Monaco
- Europe/Moscow
- Europe/Nicosia
- Europe/Oslo
- Europe/Paris
- Europe/Podgorica
- Europe/Prague
- Europe/Riga
- Europe/Rome
- Europe/Samara
- Europe/San_Marino
- Europe/Sarajevo
- Europe/Simferopol
- Europe/Skopje
- Europe/Sofia
- Europe/Stockholm
- Europe/Tallinn
- Europe/Tirane
- Europe/Tiraspol
- Europe/Uzhgorod
- Europe/Vaduz
- Europe/Vatican
- Europe/Vienna
- Europe/Vilnius
- Europe/Volgograd
- Europe/Warsaw
- Europe/Zagreb
- Europe/Zaporozhye
- Europe/Zurich
- Factory
- GB
- GB-Eire
- GMT
- GMT+0
- GMT-0
- GMT0
- Greenwich
- HST
- Hongkong
- Iceland
- Indian/Antananarivo
- Indian/Chagos
- Indian/Christmas
- Indian/Cocos
- Indian/Comoro
- Indian/Kerguelen
- Indian/Mahe
- Indian/Maldives
- Indian/Mauritius
- Indian/Mayotte
- Indian/Reunion
- Iran
- Israel
- Jamaica
- Japan
- Kwajalein
- Libya
- MET
- MST
- MST7MDT
- Mexico/BajaNorte
- Mexico/BajaSur
- Mexico/General
- Mideast/Riyadh87
- Mideast/Riyadh88
- Mideast/Riyadh89
- NZ
- NZ-CHAT
- Navajo
- PRC
- PST8PDT
- Pacific/Apia
- Pacific/Auckland
- Pacific/Chatham
- Pacific/Easter
- Pacific/Efate
- Pacific/Enderbury
- Pacific/Fakaofo
- Pacific/Fiji
- Pacific/Funafuti
- Pacific/Galapagos
- Pacific/Gambier
- Pacific/Guadalcanal
- Pacific/Guam
- Pacific/Honolulu
- Pacific/Johnston
- Pacific/Kiritimati
- Pacific/Kosrae
- Pacific/Kwajalein
- Pacific/Majuro
- Pacific/Marquesas
- Pacific/Midway
- Pacific/Nauru
- Pacific/Niue
- Pacific/Norfolk
- Pacific/Noumea
- Pacific/Pago_Pago
- Pacific/Palau
- Pacific/Pitcairn
- Pacific/Ponape
- Pacific/Port_Moresby
- Pacific/Rarotonga
- Pacific/Saipan
- Pacific/Samoa
- Pacific/Tahiti
- Pacific/Tarawa
- Pacific/Tongatapu
- Pacific/Truk
- Pacific/Wake
- Pacific/Wallis
- Pacific/Yap
- Poland
- Portugal
- ROC
- ROK
- Singapore
- Turkey
- UCT
- US/Alaska
- US/Aleutian
- US/Arizona
- US/Central
- US/East-Indiana
- US/Eastern
- US/Hawaii
- US/Indiana-Starke
- US/Michigan
- US/Mountain
- US/Pacific
- US/Pacific-New
- US/Samoa
- UTC
- Universal
- W-SU
- WET
- Zulu
lunes, 21 de abril de 2014
Server Error in '/' Application. Runtime error .NET
Cuando montamos nuestro proyecto en el servidor de .NET (por fín!), y en medio de la alegría, el entusiasmo y motivación nos hacen sentir como que nuestro hijo va a ser presentado en sociedad, es cuando nos cae un balde de agua fría al ver el siguiente error en pantalla:
Hay muchas maneras de tomar este error, la que siempre recomiendo es, antes que nada: ir por un café! Y luego seguir con los pasos básicos para atenderlo.
Realmente nunca un entorno de desarrollo, uno de pruebas y uno de producción son iguales (así te lo digan en medio de un juramento hipocrático). Por lo tanto, hay varias cosas que pudieron salir mal.
Lo que es necesario entender en este momento, es que realmente no estas viendo un error de tu aplicación, es un mensaje generalizado, que te dice que NO te va a mostrar el error, pero que "Hay un error" (pero no te lo va a mostrar, peró si está). Entonces el primer paso, es configurar el montaje en el servidor para ver el detalle del "error de nuestro trabajo".
Algunas causas que generalmente producen este error son:
Primero que todo, ese no es el verdadero error, hay que indagar para saber cuál ha sido el error, entonces estos son pasos para poder ver el verdadero error:
Para todos aquellos que llegaron a ver este desdichado artículo, los remito al lugar que debieron haber leído primero, para conocer un poco más del tema, del directamente responsable de su existencia: Microsoft y su documentación respecto a Elemento customErrors (Esquema de configuración de ASP.NET).
Hay muchas maneras de tomar este error, la que siempre recomiendo es, antes que nada: ir por un café! Y luego seguir con los pasos básicos para atenderlo.
¿Por qué tengo este error, si en desarrollo y pruebas no estaba?
Realmente nunca un entorno de desarrollo, uno de pruebas y uno de producción son iguales (así te lo digan en medio de un juramento hipocrático). Por lo tanto, hay varias cosas que pudieron salir mal.
Lo que es necesario entender en este momento, es que realmente no estas viendo un error de tu aplicación, es un mensaje generalizado, que te dice que NO te va a mostrar el error, pero que "Hay un error" (pero no te lo va a mostrar, peró si está). Entonces el primer paso, es configurar el montaje en el servidor para ver el detalle del "error de nuestro trabajo".
Algunas causas que generalmente producen este error son:
- La aplicación se ha construido para una versión diferente de Framework a la que está corriendo en el servidor.
- Falta un parámetro de configuración en el web.config y se está utilizando en el código de nuestro proyecto.
- Faltó subir un ensamblado .dll a la carpeta bin.
- Publicamos archivos .aspx que no concuerdan con los .dll de la carpeta bin.
- No se han borrado algunos archivos viejos .dll de versiones anteriores y ahora hay conflicto entre los nuevos .dll que hay en la carpeta bin
- Algunas de las librerías de terceros (.dll) están compiladas para una versión diferente de Framework que la del servidor en donde montamos nuestro proyecto.
- No hicimos pruebas antes de montar al servidor y el error siempre ha existido en nuestro código.
- El servidor no nos quiere. (Esta causa no está documentada en MSDN)
Haciendo trabajo de detectives.
Primero que todo, ese no es el verdadero error, hay que indagar para saber cuál ha sido el error, entonces estos son pasos para poder ver el verdadero error:
- Saber exactamente cuál es la versión del Framework .NET del servidor y puede ser cualquiera de las siguientes opciones: 2.0, 3.0, 3.5 y 4.0. Dependiendo de la Versión, hay diferentes alternativas, pero la general es como la menciono a continuación.
- En el archivo web.config buscar la cadena (así no exista esta configuración, así debe estar por defecto)
<customErrors mode="RemoteOnly" />
- Cambiar el valor de mode por Off y debe quedar así:
<customErrors mode="Off" />
Para todos aquellos que llegaron a ver este desdichado artículo, los remito al lugar que debieron haber leído primero, para conocer un poco más del tema, del directamente responsable de su existencia: Microsoft y su documentación respecto a Elemento customErrors (Esquema de configuración de ASP.NET).
miércoles, 19 de junio de 2013
Warning: Cannot modify header information - headers already sent by...
Situación:
Aparece este error en nuestro servidor de PHP:Warning: Cannot modify header information - headers already sent by (output started at /home/dominio/public_html/includes/functions/incrustaciones.php:496) in /home/dominio/public_html/general.php on line 108
Entendiendo el Problema:
En PHP podemos incrustar codigo para funciones recurrentes, esto lo hacemos con los siguientes comandos: include_once('archivodefunciones.php'), require('archivodefunciones.php').Estos archivos incrustados solo deben contener PHP, y debemos asegurarnos que tanto al comienzo como al final se usen los TAG de código para determinar el contenido del archivo. Estos tag son <?php al comienzo y ?> al final, entonces una estructura de un archivo incrustado debe ser:
Al comienzo:
Y al final:
Causas del problema:
El error se genera cuando hay contenido luego del cierre del archivo incrustado. Es decir, el mensaje de eeror nos indica que debemos revisar el archivo incrustaciones.php (segun nuestro ejemplo), y debemos mirar al final del documento. En pocas palabras encontraremos el archivo con el siguiente final:Solución:
Hay dos maneras de solucionar el problema:- Quitando el contenido restante luego del Tag de cierre de código.
- Quitando el Tag de cierre de código, indicando que el código de PHP no se ha terminado.
viernes, 18 de enero de 2013
A potentially dangerous Request.Form value was detected from the client
Es tal vez un error ya muy fácil de corregir por la mayoría en un sitio desarrollado en ASP.NET, pero con Framework 2.0. Sucede que en un servidor recientemente, fue necesario cambiarlo a Framework 4.0 y apareció este error.
Causas:
La principal causa de este tipo de errores es el envío en algun campo de texto de un formulario un contenido que esté encerrado en un TAG, es decir entre símbolos menor qué y mayor qué "< cualquier cosa >".
Realmente cualquier contenido entre estos símbolos no son potencialmente peligrosos, salvo cuando su contenido pueda ser comandos de ejecución tipo Javascript. Entonces nos pueden incluso infectar el sitio web de algun tipo de troyano o gusano que se replique entre los archivos de nuestro servidor.
Solución:
En Framework 4.0, es necesario poner la siguiente línea de código en el web.config entre el TAG de <system.web>:
Si alguien quiere de manera global, quitar las validaciones en todas las páginas de la aplicación, entonces es necesario incluir dentro del mismo TAG de sistem.web, el comando para evitar esta validación:
Causas:
La principal causa de este tipo de errores es el envío en algun campo de texto de un formulario un contenido que esté encerrado en un TAG, es decir entre símbolos menor qué y mayor qué "< cualquier cosa >".
Realmente cualquier contenido entre estos símbolos no son potencialmente peligrosos, salvo cuando su contenido pueda ser comandos de ejecución tipo Javascript. Entonces nos pueden incluso infectar el sitio web de algun tipo de troyano o gusano que se replique entre los archivos de nuestro servidor.
Solución:
En Framework 4.0, es necesario poner la siguiente línea de código en el web.config entre el TAG de <system.web>:
<system.web>
<httpRuntime requestValidationMode="2.0" />
</system.web>
Si alguien quiere de manera global, quitar las validaciones en todas las páginas de la aplicación, entonces es necesario incluir dentro del mismo TAG de sistem.web, el comando para evitar esta validación:
<system.web>
<pages validateRequest="false" />
</system.web>
Suscribirse a:
Entradas (Atom)
7 razones para no usar Laravel en tu proyecto de PHP
En más de 40 años de experiencia como programador y director de proyectos de programación, he aprendido que cada requerimiento tiene mejores...
-
Cuando montamos nuestro proyecto en el servidor de .NET (por fín!), y en medio de la alegría, el entusiasmo y motivación nos hacen sentir co...
-
A veces necesitamos ejecutar un script en SQL en nuestra base de datos de SQL Server, pero sin hacer uso del Agente (a veces por motivos de ...
-
Volvemos a las migraciones entre servidores... éste es a veces un problema que se nos presenta cuando ya hemos hecho casi de todo y creí...








