Re: [oracle_br] Migrando BD 11.2.0.4.0 para Forms 19.0.0.0.0
Bom Chiappa, Entendi... E muito obrigado pelas ajudas [ ]s Em segunda-feira, 25 de maio de 2020 10:08:12 BRT, Tiago de Assis Pimenta tiagopime...@ymail.com [oracle_br] escreveu: Bom dia pessoal, Entendi Chiappa, a minha dúvida era justamente se algumas dessas tools que você comentou, se ela fazia o "relacionamento" das bult-in's, ou se elas faziam algum tipo de aviso, mostrando as bult-in's que foram descontinuadas e/ou depreciadas e quais "vieram" no seu lugar. Muito Obrigado [ ]s Em sexta-feira, 22 de maio de 2020 16:59:04 BRT, Jose Laurindo Chiappa jlchia...@yahoo.com.br [oracle_br] escreveu: Por exemplo, falando de fatures/built-ins que foram REMOVIDAS mesmo depois de vários anos depreciadas, podemos exemplificar com a feature de STREAMS, no banco 19c afaik ela foi mesmo removida, Não Existe mais : é por conta do aplicador/migrador alterar os códigos/processos que dependiam de STREAMS para funcionar, nenhuma tool é disponibilizada para isso afaik O máximo que a Oracle faz é no script de pré-upgrade do 19c já te AVISAR que o banco a ser migrado contém Streams, okdoc ?? Abraços, Chiappa Em sexta-feira, 22 de maio de 2020 16:51:58 BRT, Jose Laurindo Chiappa jlchia...@yahoo.com.br [oracle_br] escreveu: às vezes, em casos MUITO pontuais, depois de vários e vários anos que a built-in foi depreciada aí SIM ela é mesmo Removida do banco , aí SIM vai haver necessidade de re-escrita da app - e nesses RAROS casos, não, a Oracle via de regra não te dá uma tool que já faça a substituição por você Abraços, Chiappa Em sexta-feira, 22 de maio de 2020 16:48:15 BRT, Jose Laurindo Chiappa jlchia...@yahoo.com.br [oracle_br] escreveu: Não sr : as tools de migração não fazem essa substituição porque ela Não É Necessária : fato é, quando uma built-in interna é depreciada/descontinuada, JUSTAMENTE para evitar re-escrita de código de apps legadas, ela CONTINUA EXISTINDO, veja o caso aqui num banco 18c dessa package dbms_obfuscation_toolkit depreciada : SID:XE::C:\Users\User 2am>sqlplus system/oracle SQL*Plus: Release 18.0.0.0.0 - Production on Sex Mai 22 16:43:32 2020 Version 18.4.0.0.0 Copyright (c) 1982, 2018, Oracle. All rights reserved. Horário do último log-in bem-sucedido: Qui Mai 21 2020 16:30:11 -03:00 Conectado a: Oracle Database 18c Express Edition Release 18.0.0.0.0 - Production Version 18.4.0.0.0 WHERE -- CONTAINER=XEPDB1 1 linha selecionada. SYSTEM@xepdb1::CONTAINER=XEPDB1> @desc dbms_obfuscation_toolkit PROCEDURE DESDECRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN DECRYPTED_DATA RAW OUT FUNCTION DESDECRYPT RETURNS RAW Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN PROCEDURE DESDECRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN DECRYPTED_STRING VARCHAR2 OUT FUNCTION DESDECRYPT RETURNS VARCHAR2 Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN PROCEDURE DESENCRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN ENCRYPTED_DATA RAW OUT FUNCTION DESENCRYPT RETURNS RAW Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN PROCEDURE DESENCRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN ENCRYPTED_STRING VARCHAR2 OUT FUNCTION DESENCRYPT RETURNS VARCHAR2 Nome do Argumento Tipo In/Out Padrão?
Re: [oracle_br] Migrando BD 11.2.0.4.0 para Forms 19.0.0.0.0
Bom dia pessoal, Entendi Chiappa, a minha dúvida era justamente se algumas dessas tools que você comentou, se ela fazia o "relacionamento" das bult-in's, ou se elas faziam algum tipo de aviso, mostrando as bult-in's que foram descontinuadas e/ou depreciadas e quais "vieram" no seu lugar. Muito Obrigado [ ]s Em sexta-feira, 22 de maio de 2020 16:59:04 BRT, Jose Laurindo Chiappa jlchia...@yahoo.com.br [oracle_br] escreveu: Por exemplo, falando de fatures/built-ins que foram REMOVIDAS mesmo depois de vários anos depreciadas, podemos exemplificar com a feature de STREAMS, no banco 19c afaik ela foi mesmo removida, Não Existe mais : é por conta do aplicador/migrador alterar os códigos/processos que dependiam de STREAMS para funcionar, nenhuma tool é disponibilizada para isso afaik O máximo que a Oracle faz é no script de pré-upgrade do 19c já te AVISAR que o banco a ser migrado contém Streams, okdoc ?? Abraços, Chiappa Em sexta-feira, 22 de maio de 2020 16:51:58 BRT, Jose Laurindo Chiappa jlchia...@yahoo.com.br [oracle_br] escreveu: às vezes, em casos MUITO pontuais, depois de vários e vários anos que a built-in foi depreciada aí SIM ela é mesmo Removida do banco , aí SIM vai haver necessidade de re-escrita da app - e nesses RAROS casos, não, a Oracle via de regra não te dá uma tool que já faça a substituição por você Abraços, Chiappa Em sexta-feira, 22 de maio de 2020 16:48:15 BRT, Jose Laurindo Chiappa jlchia...@yahoo.com.br [oracle_br] escreveu: Não sr : as tools de migração não fazem essa substituição porque ela Não É Necessária : fato é, quando uma built-in interna é depreciada/descontinuada, JUSTAMENTE para evitar re-escrita de código de apps legadas, ela CONTINUA EXISTINDO, veja o caso aqui num banco 18c dessa package dbms_obfuscation_toolkit depreciada : SID:XE::C:\Users\User 2am>sqlplus system/oracle SQL*Plus: Release 18.0.0.0.0 - Production on Sex Mai 22 16:43:32 2020 Version 18.4.0.0.0 Copyright (c) 1982, 2018, Oracle. All rights reserved. Horário do último log-in bem-sucedido: Qui Mai 21 2020 16:30:11 -03:00 Conectado a: Oracle Database 18c Express Edition Release 18.0.0.0.0 - Production Version 18.4.0.0.0 WHERE -- CONTAINER=XEPDB1 1 linha selecionada. SYSTEM@xepdb1::CONTAINER=XEPDB1> @desc dbms_obfuscation_toolkit PROCEDURE DESDECRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN DECRYPTED_DATA RAW OUT FUNCTION DESDECRYPT RETURNS RAW Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN PROCEDURE DESDECRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN DECRYPTED_STRING VARCHAR2 OUT FUNCTION DESDECRYPT RETURNS VARCHAR2 Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN PROCEDURE DESENCRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN ENCRYPTED_DATA RAW OUT FUNCTION DESENCRYPT RETURNS RAW Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN PROCEDURE DESENCRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN ENCRYPTED_STRING VARCHAR2 OUT FUNCTION DESENCRYPT RETURNS VARCHAR2 Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN PROCEDURE DESGETKEY Nome do
Re: [oracle_br] Migrando BD 11.2.0.4.0 para Forms 19.0.0.0.0
Por exemplo, falando de fatures/built-ins que foram REMOVIDAS mesmo depois de vários anos depreciadas, podemos exemplificar com a feature de STREAMS, no banco 19c afaik ela foi mesmo removida, Não Existe mais : é por conta do aplicador/migrador alterar os códigos/processos que dependiam de STREAMS para funcionar, nenhuma tool é disponibilizada para isso afaik O máximo que a Oracle faz é no script de pré-upgrade do 19c já te AVISAR que o banco a ser migrado contém Streams, okdoc ?? Abraços, Chiappa Em sexta-feira, 22 de maio de 2020 16:51:58 BRT, Jose Laurindo Chiappa jlchia...@yahoo.com.br [oracle_br] escreveu: às vezes, em casos MUITO pontuais, depois de vários e vários anos que a built-in foi depreciada aí SIM ela é mesmo Removida do banco , aí SIM vai haver necessidade de re-escrita da app - e nesses RAROS casos, não, a Oracle via de regra não te dá uma tool que já faça a substituição por você Abraços, Chiappa Em sexta-feira, 22 de maio de 2020 16:48:15 BRT, Jose Laurindo Chiappa jlchia...@yahoo.com.br [oracle_br] escreveu: Não sr : as tools de migração não fazem essa substituição porque ela Não É Necessária : fato é, quando uma built-in interna é depreciada/descontinuada, JUSTAMENTE para evitar re-escrita de código de apps legadas, ela CONTINUA EXISTINDO, veja o caso aqui num banco 18c dessa package dbms_obfuscation_toolkit depreciada : SID:XE::C:\Users\User 2am>sqlplus system/oracle SQL*Plus: Release 18.0.0.0.0 - Production on Sex Mai 22 16:43:32 2020 Version 18.4.0.0.0 Copyright (c) 1982, 2018, Oracle. All rights reserved. Horário do último log-in bem-sucedido: Qui Mai 21 2020 16:30:11 -03:00 Conectado a: Oracle Database 18c Express Edition Release 18.0.0.0.0 - Production Version 18.4.0.0.0 WHERE -- CONTAINER=XEPDB1 1 linha selecionada. SYSTEM@xepdb1::CONTAINER=XEPDB1> @desc dbms_obfuscation_toolkit PROCEDURE DESDECRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN DECRYPTED_DATA RAW OUT FUNCTION DESDECRYPT RETURNS RAW Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN PROCEDURE DESDECRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN DECRYPTED_STRING VARCHAR2 OUT FUNCTION DESDECRYPT RETURNS VARCHAR2 Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN PROCEDURE DESENCRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN ENCRYPTED_DATA RAW OUT FUNCTION DESENCRYPT RETURNS RAW Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN PROCEDURE DESENCRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN ENCRYPTED_STRING VARCHAR2 OUT FUNCTION DESENCRYPT RETURNS VARCHAR2 Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN PROCEDURE DESGETKEY Nome do Argumento Tipo In/Out Padrão? -- --- -- SEED RAW IN KEY RAW OUT FUNCTION DESGETKEY RETURNS RAW Nome do Argumento Tipo In/Out Padrão? -- --- -- SEED
Re: [oracle_br] Migrando BD 11.2.0.4.0 para Forms 19.0.0.0.0
às vezes, em casos MUITO pontuais, depois de vários e vários anos que a built-in foi depreciada aí SIM ela é mesmo Removida do banco , aí SIM vai haver necessidade de re-escrita da app - e nesses RAROS casos, não, a Oracle via de regra não te dá uma tool que já faça a substituição por você Abraços, Chiappa Em sexta-feira, 22 de maio de 2020 16:48:15 BRT, Jose Laurindo Chiappa jlchia...@yahoo.com.br [oracle_br] escreveu: Não sr : as tools de migração não fazem essa substituição porque ela Não É Necessária : fato é, quando uma built-in interna é depreciada/descontinuada, JUSTAMENTE para evitar re-escrita de código de apps legadas, ela CONTINUA EXISTINDO, veja o caso aqui num banco 18c dessa package dbms_obfuscation_toolkit depreciada : SID:XE::C:\Users\User 2am>sqlplus system/oracle SQL*Plus: Release 18.0.0.0.0 - Production on Sex Mai 22 16:43:32 2020 Version 18.4.0.0.0 Copyright (c) 1982, 2018, Oracle. All rights reserved. Horário do último log-in bem-sucedido: Qui Mai 21 2020 16:30:11 -03:00 Conectado a: Oracle Database 18c Express Edition Release 18.0.0.0.0 - Production Version 18.4.0.0.0 WHERE -- CONTAINER=XEPDB1 1 linha selecionada. SYSTEM@xepdb1::CONTAINER=XEPDB1> @desc dbms_obfuscation_toolkit PROCEDURE DESDECRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN DECRYPTED_DATA RAW OUT FUNCTION DESDECRYPT RETURNS RAW Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN PROCEDURE DESDECRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN DECRYPTED_STRING VARCHAR2 OUT FUNCTION DESDECRYPT RETURNS VARCHAR2 Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN PROCEDURE DESENCRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN ENCRYPTED_DATA RAW OUT FUNCTION DESENCRYPT RETURNS RAW Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN PROCEDURE DESENCRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN ENCRYPTED_STRING VARCHAR2 OUT FUNCTION DESENCRYPT RETURNS VARCHAR2 Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN PROCEDURE DESGETKEY Nome do Argumento Tipo In/Out Padrão? -- --- -- SEED RAW IN KEY RAW OUT FUNCTION DESGETKEY RETURNS RAW Nome do Argumento Tipo In/Out Padrão? -- --- -- SEED RAW IN PROCEDURE DESGETKEY Nome do Argumento Tipo In/Out Padrão? -- --- -- SEED_STRING VARCHAR2 IN KEY VARCHAR2 OUT FUNCTION DESGETKEY RETURNS VARCHAR2 Nome do Argumento Tipo In/Out Padrão? -- --- -- SEED_STRING VARCHAR2 IN PROCEDURE DES3DECRYPT Nome do Argumento Tipo
Re: [oracle_br] Migrando BD 11.2.0.4.0 para Forms 19.0.0.0.0
Não sr : as tools de migração não fazem essa substituição porque ela Não É Necessária : fato é, quando uma built-in interna é depreciada/descontinuada, JUSTAMENTE para evitar re-escrita de código de apps legadas, ela CONTINUA EXISTINDO, veja o caso aqui num banco 18c dessa package dbms_obfuscation_toolkit depreciada : SID:XE::C:\Users\User 2am>sqlplus system/oracle SQL*Plus: Release 18.0.0.0.0 - Production on Sex Mai 22 16:43:32 2020 Version 18.4.0.0.0 Copyright (c) 1982, 2018, Oracle. All rights reserved. Horário do último log-in bem-sucedido: Qui Mai 21 2020 16:30:11 -03:00 Conectado a: Oracle Database 18c Express Edition Release 18.0.0.0.0 - Production Version 18.4.0.0.0 WHERE -- CONTAINER=XEPDB1 1 linha selecionada. SYSTEM@xepdb1::CONTAINER=XEPDB1> @desc dbms_obfuscation_toolkit PROCEDURE DESDECRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN DECRYPTED_DATA RAW OUT FUNCTION DESDECRYPT RETURNS RAW Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN PROCEDURE DESDECRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN DECRYPTED_STRING VARCHAR2 OUT FUNCTION DESDECRYPT RETURNS VARCHAR2 Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN PROCEDURE DESENCRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN ENCRYPTED_DATA RAW OUT FUNCTION DESENCRYPT RETURNS RAW Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN PROCEDURE DESENCRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN ENCRYPTED_STRING VARCHAR2 OUT FUNCTION DESENCRYPT RETURNS VARCHAR2 Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT_STRING VARCHAR2 IN KEY_STRING VARCHAR2 IN PROCEDURE DESGETKEY Nome do Argumento Tipo In/Out Padrão? -- --- -- SEED RAW IN KEY RAW OUT FUNCTION DESGETKEY RETURNS RAW Nome do Argumento Tipo In/Out Padrão? -- --- -- SEED RAW IN PROCEDURE DESGETKEY Nome do Argumento Tipo In/Out Padrão? -- --- -- SEED_STRING VARCHAR2 IN KEY VARCHAR2 OUT FUNCTION DESGETKEY RETURNS VARCHAR2 Nome do Argumento Tipo In/Out Padrão? -- --- -- SEED_STRING VARCHAR2 IN PROCEDURE DES3DECRYPT Nome do Argumento Tipo In/Out Padrão? -- --- -- INPUT RAW IN KEY RAW IN DECRYPTED_DATA RAW OUT WHICH BINARY_INTEGER IN DEFAULT IV RAW IN DEFAULT FUNCTION DES3DECRYPT RETURNS RAW Nome
Re: [oracle_br] Migrando BD 11.2.0.4.0 para Forms 19.0.0.0.0
Eu entendi Chiappa, acho que não fui claro ao fazer a pergunta... Para o meu caso do type JSON customizado no banco 11g, não há ferramentas que possam me ajudar, isso já está entendido. A minha pergunta foi em relação a pacotes nativos do Oracle que foram substituídos, vou dar uma exemplo, no 11g, existia um pacote chamado "dbms_obfuscation_toolkit", que na própria documentação da Oracle ( https://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_obtool..htm#ARPLS028 ), diz que foi descontinuada(deprecated) e que o pacote chamado "dbms_crypto", substitui o pacote "dbms_obfuscation_toolkit". As ferramentas que você comentou, nesse caso dos pacotes "dbms_obfuscation_toolkit" e "dbms_crypto", fariam essa "migração" ? [ ]sEm sexta-feira, 22 de maio de 2020 13:44:30 BRT, Jose Laurindo Chiappa jlchia...@yahoo.com.br [oracle_br] escreveu: NÃO, colega!!! Plz RELEIA a minha resposta, eu disse " E sendo customizado NÃO TEM COMO as tools de migração da Oracle fazerem qquer conversão automáticamente para vc" - e justamente o CONTRÁRIO, NÃO TEM ferramenta alguma que faça mudança em código customizado não-Oracle Em quinta-feira, 21 de maio de 2020 18:04:41 BRT, Tiago de Assis Pimenta tiagopime...@ymail.com [oracle_br] escreveu: Boa tarde Chiappa, tudo bem ??? Desculpa a demora, mas com esses feriados relâmpagos, ficou tudo mais confuso ainda *rs* Perfeito Chiappa, sobre as tools de migração, existe então ferramentas que, quando os recursos nativos do Oracle, mudam de nome, essas ferramentas ajudam a fazer essa migração ? Não conhecia essa possibilidade. [ ]sEm segunda-feira, 18 de maio de 2020 11:44:19 BRT, Jose Laurindo Chiappa jlchia...@yahoo.com.br [oracle_br] escreveu: Sim sr : com Absoluta Certeza já existe um objeto chamado JSON_VALUE , criado de OUTRA maneira pelo Oracle : se vc olhar a documentação Oracle do 12c em https://docs..oracle.com/database/121/SQLRF/functions093..htm#SQLRF56668 vc JÁ VAI VER que no 12c já foi introduzida uma FUNÇÃO INTERNA com esse nome Então SIM, concordo com sua análise : lá na época do 11g alguém construiu um código CUSTOMIZADO, com objetos CUSTOMIZADOS para simular as funções JSON que o Oracle 11 não tinha E não tem, agora por Casualidade no 19c algum/alguns desse(s) construtos e códigos CUSTOMIZADOS estão conflitando com o código/construtos JSON built-in da Oracle E sendo customizado NÂO TEM COMO as tools de migração da Oracle fazerem qquer conversão automáticamente para vc, código CUSTOMIZADO é por definição código DE USUÁRIO, Não-Oracle. Suas duas alternativas então são : 1. RENOMEAR / reconstruir os objetos E códigos da solução JSON customizada aí presente para que NÃO CONFLITEM com o que o banco 12c em diante (e 19c inclusive, óbvio) já trazem OU 2. recodificar a aplicação para que passe a usar os NOVOS objetos E as novas built-in JSON do Oracle, ao invés de querer implementar o código customizado antigo que simulava os objetos/códigos JSON okdoc ?? OU SEJA, de qquer forma vc VAI TER QUE levantar quem e de que forma criou a solução JSON customizada aí no 11g E DEPOIS analisar se é mais fácil (em termos de esforço) adaptar nomes e objetos dela OU a alterar para usar os built-ins Oracle. É uma tarefa LOCAL que ninguém pode fazer por você : no máximo, SE os desenvolvedores da solução json 11g optaram por re-usar um código publicamente disponível (como https://sourceforge.net/p/pljson/wiki/Home/ , por exemplo) TALVEZ algum desenvolvedor que já usava o mesmo código público possa te dar umas dicas mais, MAS se na verdade os devs optaram por criar código PRÓPRIO para simular o JSON em 11g aí só ELES é que podem alterar isso Abraços, José Laurindo Chiappa Em sábado, 16 de maio de 2020 01:50:47 BRT, Tiago de Assis Pimenta tiagopime...@ymail.com [oracle_br] escreveu: Chiappa, JSON, XML e qualquer coisa relacionada, não entendo muito, então se eu falar alguma besteira, me desculpe. Pelo que eu entendi até agora, no 11g a empresa criou um "type JSON as object", e os construtores são: constructor function json return self as result,constructor function json(str varchar2) return self as result,constructor function json(str in clob) return self as result,constructor function json(cast json_value) return self as result,constructor function json(l in out nocopy json_list) return self as result Quando abri esse type "JSON", o erro está na linha: "json_data json_value_array," Abrindo o type "JSON_VALUE_ARRAY", o erro está na linha: "CREATE OR REPLACE TYPE "JSON_VALUE_ARRAY" as table of json_value;" O erro é: "Compilation errors for TYPE UMBRELLA.JSON_VALUE_ARRAY Error: PLS-00488: 'JSON_VALUE' must be a typeLine: 1Text: CREATE OR REPLACE TYPE "JSON_VALUE_ARRAY" as table of json_value; Error: PL/SQL: Compilation unit analysis terminatedLine: 1Text: CREATE OR REPLACE TYPE "JSON_VALUE_ARRAY" as table of json_value;" Outra pessoa
Re: [oracle_br] Migrando BD 11.2.0.4.0 para Forms 19.0.0.0.0
NÃO, colega!!! Plz RELEIA a minha resposta, eu disse " E sendo customizado NÃO
TEM COMO as tools de migração da Oracle fazerem qquer conversão automáticamente
para vc" - e justamente o CONTRÁRIO, NÃO TEM ferramenta alguma que faça
mudança em código customizado não-Oracle
Em quinta-feira, 21 de maio de 2020 18:04:41 BRT, Tiago de Assis Pimenta
tiagopime...@ymail.com [oracle_br] escreveu:
#yiv9562940478 #yiv9562940478 -- #yiv9562940478
.yiv9562940478ygrp-photo-title{clear:both;font-size:smaller;min-height:15px;overflow:hidden;text-align:center;width:75px;}#yiv9562940478
div.yiv9562940478ygrp-photo{background-position:center;background-repeat:no-repeat;background-color:white;border:1px
solid black;min-height:62px;width:62px;}#yiv9562940478
div.yiv9562940478photo-title a, #yiv9562940478 div.yiv9562940478photo-title
a:active, #yiv9562940478 div.yiv9562940478photo-title a:hover, #yiv9562940478
div.yiv9562940478photo-title a:visited {text-decoration:none;}#yiv9562940478
div.yiv9562940478attach-table div.yiv9562940478attach-row
{clear:both;}#yiv9562940478 div.yiv9562940478attach-table
div.yiv9562940478attach-row div {float:left;}#yiv9562940478 p
{clear:both;padding:15px 0 3px 0;overflow:hidden;}#yiv9562940478
div.yiv9562940478ygrp-file {width:30px;}#yiv9562940478
div.yiv9562940478attach-table div.yiv9562940478attach-row div div a
{text-decoration:none;}#yiv9562940478 div.yiv9562940478attach-table
div.yiv9562940478attach-row div div span {font-weight:normal;}#yiv9562940478
div.yiv9562940478ygrp-file-title {font-weight:bold;}#yiv9562940478
#yiv9562940478
Boa tarde Chiappa, tudo bem ???
Desculpa a demora, mas com esses feriados relâmpagos, ficou tudo mais confuso
ainda *rs*
Perfeito Chiappa, sobre as tools de migração, existe então ferramentas que,
quando os recursos nativos do Oracle, mudam de nome, essas ferramentas ajudam a
fazer essa migração ? Não conhecia essa possibilidade.
[ ]sEm segunda-feira, 18 de maio de 2020 11:44:19 BRT, Jose Laurindo
Chiappa jlchia...@yahoo.com.br [oracle_br]
escreveu:
Sim sr : com Absoluta Certeza já existe um objeto chamado JSON_VALUE , criado
de OUTRA maneira pelo Oracle : se vc olhar a documentação Oracle do 12c em
https://docs..oracle.com/database/121/SQLRF/functions093..htm#SQLRF56668 vc JÁ
VAI VER que no 12c já foi introduzida uma FUNÇÃO INTERNA com esse nome
Então SIM, concordo com sua análise : lá na época do 11g alguém construiu um
código CUSTOMIZADO, com objetos CUSTOMIZADOS para simular as funções JSON que o
Oracle 11 não tinha E não tem, agora por Casualidade no 19c algum/alguns
desse(s) construtos e códigos CUSTOMIZADOS estão conflitando com o
código/construtos JSON built-in da Oracle E sendo customizado NÂO TEM COMO
as tools de migração da Oracle fazerem qquer conversão automáticamente para vc,
código CUSTOMIZADO é por definição código DE USUÁRIO, Não-Oracle.
Suas duas alternativas então são :
1. RENOMEAR / reconstruir os objetos E códigos da solução JSON customizada aí
presente para que NÃO CONFLITEM com o que o banco 12c em diante (e 19c
inclusive, óbvio) já trazem
OU
2. recodificar a aplicação para que passe a usar os NOVOS objetos E as novas
built-in JSON do Oracle, ao invés de querer implementar o código customizado
antigo que simulava os objetos/códigos JSON
okdoc ?? OU SEJA, de qquer forma vc VAI TER QUE levantar quem e de que forma
criou a solução JSON customizada aí no 11g E DEPOIS analisar se é mais fácil
(em termos de esforço) adaptar nomes e objetos dela OU a alterar para usar os
built-ins Oracle. É uma tarefa LOCAL que ninguém pode fazer por você : no
máximo, SE os desenvolvedores da solução json 11g optaram por re-usar um código
publicamente disponível (como https://sourceforge.net/p/pljson/wiki/Home/ , por
exemplo) TALVEZ algum desenvolvedor que já usava o mesmo código público possa
te dar umas dicas mais, MAS se na verdade os devs optaram por criar código
PRÓPRIO para simular o JSON em 11g aí só ELES é que podem alterar isso
Abraços,
José Laurindo Chiappa
Em sábado, 16 de maio de 2020 01:50:47 BRT, Tiago de Assis Pimenta
tiagopime...@ymail.com [oracle_br] escreveu:
Chiappa,
JSON, XML e qualquer coisa relacionada, não entendo muito, então se eu falar
alguma besteira, me desculpe.
Pelo que eu entendi até agora, no 11g a empresa criou um "type JSON as object",
e os construtores são:
constructor function json return self as result,constructor function json(str
varchar2) return self as result,constructor function json(str in clob) return
self as result,constructor function json(cast json_value) return self as
result,constructor function json(l in out nocopy json_list) return self as
result Quando abri esse type "JSON", o erro está na linha:
"json_data json_value_array,"
Abrindo o type "JSON_VALUE_ARRAY", o erro está na linha:
"CREATE OR REPLACE TYPE "JSON_VALUE_ARRAY" as table of json_value;"
O erro é:
Re: [oracle_br] Migrando BD 11.2.0.4.0 para Forms 19.0.0.0.0
Boa tarde Chiappa, tudo bem ??? Desculpa a demora, mas com esses feriados relâmpagos, ficou tudo mais confuso ainda *rs* Perfeito Chiappa, sobre as tools de migração, existe então ferramentas que, quando os recursos nativos do Oracle, mudam de nome, essas ferramentas ajudam a fazer essa migração ? Não conhecia essa possibilidade. [ ]sEm segunda-feira, 18 de maio de 2020 11:44:19 BRT, Jose Laurindo Chiappa jlchia...@yahoo.com.br [oracle_br] escreveu: Sim sr : com Absoluta Certeza já existe um objeto chamado JSON_VALUE , criado de OUTRA maneira pelo Oracle : se vc olhar a documentação Oracle do 12c em https://docs..oracle.com/database/121/SQLRF/functions093..htm#SQLRF56668 vc JÁ VAI VER que no 12c já foi introduzida uma FUNÇÃO INTERNA com esse nome Então SIM, concordo com sua análise : lá na época do 11g alguém construiu um código CUSTOMIZADO, com objetos CUSTOMIZADOS para simular as funções JSON que o Oracle 11 não tinha E não tem, agora por Casualidade no 19c algum/alguns desse(s) construtos e códigos CUSTOMIZADOS estão conflitando com o código/construtos JSON built-in da Oracle E sendo customizado NÂO TEM COMO as tools de migração da Oracle fazerem qquer conversão automáticamente para vc, código CUSTOMIZADO é por definição código DE USUÁRIO, Não-Oracle. Suas duas alternativas então são : 1. RENOMEAR / reconstruir os objetos E códigos da solução JSON customizada aí presente para que NÃO CONFLITEM com o que o banco 12c em diante (e 19c inclusive, óbvio) já trazem OU 2. recodificar a aplicação para que passe a usar os NOVOS objetos E as novas built-in JSON do Oracle, ao invés de querer implementar o código customizado antigo que simulava os objetos/códigos JSON okdoc ?? OU SEJA, de qquer forma vc VAI TER QUE levantar quem e de que forma criou a solução JSON customizada aí no 11g E DEPOIS analisar se é mais fácil (em termos de esforço) adaptar nomes e objetos dela OU a alterar para usar os built-ins Oracle. É uma tarefa LOCAL que ninguém pode fazer por você : no máximo, SE os desenvolvedores da solução json 11g optaram por re-usar um código publicamente disponível (como https://sourceforge.net/p/pljson/wiki/Home/ , por exemplo) TALVEZ algum desenvolvedor que já usava o mesmo código público possa te dar umas dicas mais, MAS se na verdade os devs optaram por criar código PRÓPRIO para simular o JSON em 11g aí só ELES é que podem alterar isso Abraços, José Laurindo Chiappa Em sábado, 16 de maio de 2020 01:50:47 BRT, Tiago de Assis Pimenta tiagopime...@ymail.com [oracle_br] escreveu: Chiappa, JSON, XML e qualquer coisa relacionada, não entendo muito, então se eu falar alguma besteira, me desculpe. Pelo que eu entendi até agora, no 11g a empresa criou um "type JSON as object", e os construtores são: constructor function json return self as result,constructor function json(str varchar2) return self as result,constructor function json(str in clob) return self as result,constructor function json(cast json_value) return self as result,constructor function json(l in out nocopy json_list) return self as result Quando abri esse type "JSON", o erro está na linha: "json_data json_value_array," Abrindo o type "JSON_VALUE_ARRAY", o erro está na linha: "CREATE OR REPLACE TYPE "JSON_VALUE_ARRAY" as table of json_value;" O erro é: "Compilation errors for TYPE UMBRELLA.JSON_VALUE_ARRAY Error: PLS-00488: 'JSON_VALUE' must be a typeLine: 1Text: CREATE OR REPLACE TYPE "JSON_VALUE_ARRAY" as table of json_value; Error: PL/SQL: Compilation unit analysis terminatedLine: 1Text: CREATE OR REPLACE TYPE "JSON_VALUE_ARRAY" as table of json_value;" Outra pessoa que está me ajudando nessa jornada, me pediu para criar alguns sinônimos, entre eles, o json_value "create synonym json_value for pljson_value;" E não está criando, pelo que eu entendi, pois existe um type já com esse nome, é isso ?? [ ]sEm sexta-feira, 15 de maio de 2020 19:28:49 BRT, Jose Laurindo Chiappa jlchia...@yahoo.com.br [oracle_br] escreveu: Ah, e outro detalhe importante : como o datatype JSON foi introduzido no 12c mas sofreu ** várias ** melhorias no 18c e 19c, tenha Certeza de que tudo que vc fizer é com a ÚLTIMA VERSÃO, mais Atualizada possível, do PL/SQL Developer OU então (melhor) use o Oracle SQL DEVELOPER 19.x ou o sql*plus 19..x que veio junbto com o RDBMS Oracle 19c Abraços, Chiappa Em sexta-feira, 15 de maio de 2020 19:16:32 BRT, Jose Laurindo Chiappa escreveu: Blz ? Então, primeira coisa até onde sei no Oracle 11g ** absolutamente Não Existia ** um datatype nativo para JSON, vide https://asktom.oracle.com/pls/apex/asktom.search?tag=converting-json-data-into-oracle-11g Pra começarmos a entender a sua situação, plz nos explique QUAL datatype vc usou realmente nas tabelas 11g (provavelmente deve ter sido CLOB, já que um JSON nada mais é do que um texto), e COMO vc fazia a conversão/validação
Re: [oracle_br] Migrando BD 11.2.0.4.0 para Forms 19.0.0.0.0
Sim sr : com Absoluta Certeza já existe um objeto chamado JSON_VALUE , criado
de OUTRA maneira pelo Oracle : se vc olhar a documentação Oracle do 12c em
https://docs.oracle.com/database/121/SQLRF/functions093.htm#SQLRF56668 vc JÁ
VAI VER que no 12c já foi introduzida uma FUNÇÃO INTERNA com esse nome
Então SIM, concordo com sua análise : lá na época do 11g alguém construiu um
código CUSTOMIZADO, com objetos CUSTOMIZADOS para simular as funções JSON que o
Oracle 11 não tinha E não tem, agora por Casualidade no 19c algum/alguns
desse(s) construtos e códigos CUSTOMIZADOS estão conflitando com o
código/construtos JSON built-in da Oracle E sendo customizado NÂO TEM COMO
as tools de migração da Oracle fazerem qquer conversão automáticamente para vc,
código CUSTOMIZADO é por definição código DE USUÁRIO, Não-Oracle.
Suas duas alternativas então são :
1. RENOMEAR / reconstruir os objetos E códigos da solução JSON customizada aí
presente para que NÃO CONFLITEM com o que o banco 12c em diante (e 19c
inclusive, óbvio) já trazem
OU
2. recodificar a aplicação para que passe a usar os NOVOS objetos E as novas
built-in JSON do Oracle, ao invés de querer implementar o código customizado
antigo que simulava os objetos/códigos JSON
okdoc ?? OU SEJA, de qquer forma vc VAI TER QUE levantar quem e de que forma
criou a solução JSON customizada aí no 11g E DEPOIS analisar se é mais fácil
(em termos de esforço) adaptar nomes e objetos dela OU a alterar para usar os
built-ins Oracle. É uma tarefa LOCAL que ninguém pode fazer por você : no
máximo, SE os desenvolvedores da solução json 11g optaram por re-usar um código
publicamente disponível (como https://sourceforge.net/p/pljson/wiki/Home/ , por
exemplo) TALVEZ algum desenvolvedor que já usava o mesmo código público possa
te dar umas dicas mais, MAS se na verdade os devs optaram por criar código
PRÓPRIO para simular o JSON em 11g aí só ELES é que podem alterar isso
Abraços,
José Laurindo Chiappa
Em sábado, 16 de maio de 2020 01:50:47 BRT, Tiago de Assis Pimenta
tiagopime...@ymail.com [oracle_br] escreveu:
#yiv6385919433 #yiv6385919433 -- #yiv6385919433
.yiv6385919433ygrp-photo-title{clear:both;font-size:smaller;min-height:15px;overflow:hidden;text-align:center;width:75px;}#yiv6385919433
div.yiv6385919433ygrp-photo{background-position:center;background-repeat:no-repeat;background-color:white;border:1px
solid black;min-height:62px;width:62px;}#yiv6385919433
div.yiv6385919433photo-title a, #yiv6385919433 div.yiv6385919433photo-title
a:active, #yiv6385919433 div.yiv6385919433photo-title a:hover, #yiv6385919433
div.yiv6385919433photo-title a:visited {text-decoration:none;}#yiv6385919433
div.yiv6385919433attach-table div.yiv6385919433attach-row
{clear:both;}#yiv6385919433 div.yiv6385919433attach-table
div.yiv6385919433attach-row div {float:left;}#yiv6385919433 p
{clear:both;padding:15px 0 3px 0;overflow:hidden;}#yiv6385919433
div.yiv6385919433ygrp-file {width:30px;}#yiv6385919433
div.yiv6385919433attach-table div.yiv6385919433attach-row div div a
{text-decoration:none;}#yiv6385919433 div.yiv6385919433attach-table
div.yiv6385919433attach-row div div span {font-weight:normal;}#yiv6385919433
div.yiv6385919433ygrp-file-title {font-weight:bold;}#yiv6385919433
#yiv6385919433
Chiappa,
JSON, XML e qualquer coisa relacionada, não entendo muito, então se eu falar
alguma besteira, me desculpe.
Pelo que eu entendi até agora, no 11g a empresa criou um "type JSON as object",
e os construtores são:
constructor function json return self as result,constructor function json(str
varchar2) return self as result,constructor function json(str in clob) return
self as result,constructor function json(cast json_value) return self as
result,constructor function json(l in out nocopy json_list) return self as
result Quando abri esse type "JSON", o erro está na linha:
"json_data json_value_array,"
Abrindo o type "JSON_VALUE_ARRAY", o erro está na linha:
"CREATE OR REPLACE TYPE "JSON_VALUE_ARRAY" as table of json_value;"
O erro é:
"Compilation errors for TYPE UMBRELLA.JSON_VALUE_ARRAY
Error: PLS-00488: 'JSON_VALUE' must be a typeLine: 1Text: CREATE OR REPLACE
TYPE "JSON_VALUE_ARRAY" as table of json_value;
Error: PL/SQL: Compilation unit analysis terminatedLine: 1Text: CREATE OR
REPLACE TYPE "JSON_VALUE_ARRAY" as table of json_value;"
Outra pessoa que está me ajudando nessa jornada, me pediu para criar alguns
sinônimos, entre eles, o json_value
"create synonym json_value for pljson_value;"
E não está criando, pelo que eu entendi, pois existe um type já com esse nome,
é isso ??
[ ]sEm sexta-feira, 15 de maio de 2020 19:28:49 BRT, Jose Laurindo Chiappa
jlchia...@yahoo.com.br [oracle_br] escreveu:
Ah, e outro detalhe importante : como o datatype JSON foi introduzido no 12c
mas sofreu ** várias ** melhorias no 18c e 19c, tenha Certeza de que tudo que
vc fizer é com a ÚLTIMA VERSÃO,
Re: [oracle_br] Migrando BD 11.2.0.4.0 para Forms 19.0.0.0.0
Chiappa,
JSON, XML e qualquer coisa relacionada, não entendo muito, então se eu falar
alguma besteira, me desculpe.
Pelo que eu entendi até agora, no 11g a empresa criou um "type JSON as object",
e os construtores são:
constructor function json return self as result,constructor function json(str
varchar2) return self as result,constructor function json(str in clob) return
self as result,constructor function json(cast json_value) return self as
result,constructor function json(l in out nocopy json_list) return self as
result Quando abri esse type "JSON", o erro está na linha:
"json_data json_value_array,"
Abrindo o type "JSON_VALUE_ARRAY", o erro está na linha:
"CREATE OR REPLACE TYPE "JSON_VALUE_ARRAY" as table of json_value;"
O erro é:
"Compilation errors for TYPE UMBRELLA.JSON_VALUE_ARRAY
Error: PLS-00488: 'JSON_VALUE' must be a typeLine: 1Text: CREATE OR REPLACE
TYPE "JSON_VALUE_ARRAY" as table of json_value;
Error: PL/SQL: Compilation unit analysis terminatedLine: 1Text: CREATE OR
REPLACE TYPE "JSON_VALUE_ARRAY" as table of json_value;"
Outra pessoa que está me ajudando nessa jornada, me pediu para criar alguns
sinônimos, entre eles, o json_value
"create synonym json_value for pljson_value;"
E não está criando, pelo que eu entendi, pois existe um type já com esse nome,
é isso ??
[ ]sEm sexta-feira, 15 de maio de 2020 19:28:49 BRT, Jose Laurindo Chiappa
jlchia...@yahoo.com.br [oracle_br] escreveu:
Ah, e outro detalhe importante : como o datatype JSON foi introduzido no 12c
mas sofreu ** várias ** melhorias no 18c e 19c, tenha Certeza de que tudo que
vc fizer é com a ÚLTIMA VERSÃO, mais Atualizada possível, do PL/SQL Developer
OU então (melhor) use o Oracle SQL DEVELOPER 19.x ou o sql*plus 19..x que veio
junbto com o RDBMS Oracle 19c
Abraços,
Chiappa
Em sexta-feira, 15 de maio de 2020 19:16:32 BRT, Jose Laurindo Chiappa
escreveu:
Blz ? Então, primeira coisa até onde sei no Oracle 11g ** absolutamente Não
Existia ** um datatype nativo para JSON, vide
https://asktom.oracle.com/pls/apex/asktom.search?tag=converting-json-data-into-oracle-11g
Pra começarmos a entender a sua situação, plz nos explique QUAL datatype
vc usou realmente nas tabelas 11g (provavelmente deve ter sido CLOB, já que um
JSON nada mais é do que um texto), e COMO vc fazia a conversão/validação para
JSON (no 11g provavelmente vc devia estar usando as packages do APEX,
imagino)...
Abraços,
Chiappa
Em sexta-feira, 15 de maio de 2020 14:39:44 BRT, Tiago de Assis Pimenta
tiagopime...@ymail.com [oracle_br] escreveu:
Pessoal, boa tarde, tudo bem ???
Na empresa que trabalho, estamos com esse projeto de migrar o database da
versão 11.2.0.4.0 para 19.0.0.0.0, porém, estamos com alguns objetos inválidos,
acredito eu, por causa do type JSON, que no 11 não era nativo e se não me
engano, a partir da versão 12, já é nativo.
Dei uma olhada em alguns docs da Oracle sobre a migração do database, mas
nenhum ainda que eu vi, fala sobre as diferenças entre o JSON do 11g para o 19c
Alguém passou por isso ? Ou que possa me passar o caminho das pedras ?
- Dados do Ambiente -
SO Desenvolvimento: Windows 10 64bitsPL/SQL Developer: 14.0.0.1961 (64 bit)
Banco: Connected to Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0
- Um dos Vários Erros -
Compilation errors for TYPE BODY BASE.JSON
Error: PLS-00103: Encountered the symbol "." when expecting one of the
following:
(
Line: 80
Text: insert_value json_value := nvl(pair_value, json_value.makenull);
Obrigado.
#yiv8126918462 #yiv8126918462 -- #yiv8126918462ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8126918462
#yiv8126918462ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8126918462
#yiv8126918462ygrp-mkp #yiv8126918462hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv8126918462 #yiv8126918462ygrp-mkp #yiv8126918462ads
{margin-bottom:10px;}#yiv8126918462 #yiv8126918462ygrp-mkp .yiv8126918462ad
{padding:0 0;}#yiv8126918462 #yiv8126918462ygrp-mkp .yiv8126918462ad p
{margin:0;}#yiv8126918462 #yiv8126918462ygrp-mkp .yiv8126918462ad a
{color:#ff;text-decoration:none;}#yiv8126918462 #yiv8126918462ygrp-sponsor
#yiv8126918462ygrp-lc {font-family:Arial;}#yiv8126918462
#yiv8126918462ygrp-sponsor #yiv8126918462ygrp-lc #yiv8126918462hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8126918462
#yiv8126918462ygrp-sponsor #yiv8126918462ygrp-lc .yiv8126918462ad
{margin-bottom:10px;padding:0 0;}#yiv8126918462 #yiv8126918462actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8126918462
#yiv8126918462activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8126918462
#yiv8126918462activity span {font-weight:700;}#yiv8126918462
#yiv8126918462activity span:first-child
{text-transform:uppercase;}#yiv8126918462 #yiv8126918462activity span a
Re: [oracle_br] Migrando BD 11.2.0.4.0 para Forms 19.0.0.0.0
Ah, e outro detalhe importante : como o datatype JSON foi introduzido no 12c
mas sofreu ** várias ** melhorias no 18c e 19c, tenha Certeza de que tudo que
vc fizer é com a ÚLTIMA VERSÃO, mais Atualizada possível, do PL/SQL Developer
OU então (melhor) use o Oracle SQL DEVELOPER 19.x ou o sql*plus 19.x que veio
junbto com o RDBMS Oracle 19c
Abraços,
Chiappa
Em sexta-feira, 15 de maio de 2020 19:16:32 BRT, Jose Laurindo Chiappa
escreveu:
Blz ? Então, primeira coisa até onde sei no Oracle 11g ** absolutamente Não
Existia ** um datatype nativo para JSON, vide
https://asktom.oracle.com/pls/apex/asktom.search?tag=converting-json-data-into-oracle-11g
Pra começarmos a entender a sua situação, plz nos explique QUAL datatype
vc usou realmente nas tabelas 11g (provavelmente deve ter sido CLOB, já que um
JSON nada mais é do que um texto), e COMO vc fazia a conversão/validação para
JSON (no 11g provavelmente vc devia estar usando as packages do APEX,
imagino)...
Abraços,
Chiappa
Em sexta-feira, 15 de maio de 2020 14:39:44 BRT, Tiago de Assis Pimenta
tiagopime...@ymail.com [oracle_br] escreveu:
#yiv7827477568 #yiv7827477568 --
.yiv7827477568ygrp-photo-title{clear:both;font-size:smaller;min-height:15px;overflow:hidden;text-align:center;width:75px;}#yiv7827477568
div.yiv7827477568ygrp-photo{background-position:center;background-repeat:no-repeat;background-color:white;border:1px
solid black;min-height:62px;width:62px;}#yiv7827477568
div.yiv7827477568photo-title a, #yiv7827477568 div.yiv7827477568photo-title
a:active, #yiv7827477568 div.yiv7827477568photo-title a:hover, #yiv7827477568
div.yiv7827477568photo-title a:visited {text-decoration:none;}#yiv7827477568
div.yiv7827477568attach-table div.yiv7827477568attach-row
{clear:both;}#yiv7827477568 div.yiv7827477568attach-table
div.yiv7827477568attach-row div {float:left;}#yiv7827477568 p
{clear:both;padding:15px 0 3px 0;overflow:hidden;}#yiv7827477568
div.yiv7827477568ygrp-file {width:30px;}#yiv7827477568
div.yiv7827477568attach-table div.yiv7827477568attach-row div div a
{text-decoration:none;}#yiv7827477568 div.yiv7827477568attach-table
div.yiv7827477568attach-row div div span {font-weight:normal;}#yiv7827477568
div.yiv7827477568ygrp-file-title {font-weight:bold;}#yiv7827477568
Pessoal, boa tarde, tudo bem ???
Na empresa que trabalho, estamos com esse projeto de migrar o database da
versão 11.2.0.4.0 para 19.0.0.0.0, porém, estamos com alguns objetos inválidos,
acredito eu, por causa do type JSON, que no 11 não era nativo e se não me
engano, a partir da versão 12, já é nativo.
Dei uma olhada em alguns docs da Oracle sobre a migração do database, mas
nenhum ainda que eu vi, fala sobre as diferenças entre o JSON do 11g para o 19c
Alguém passou por isso ? Ou que possa me passar o caminho das pedras ?
- Dados do Ambiente -
SO Desenvolvimento: Windows 10 64bitsPL/SQL Developer: 14.0.0.1961 (64 bit)
Banco: Connected to Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0
- Um dos Vários Erros -
Compilation errors for TYPE BODY BASE.JSON
Error: PLS-00103: Encountered the symbol "." when expecting one of the
following:
(
Line: 80
Text: insert_value json_value := nvl(pair_value, json_value.makenull);
Obrigado.
Re: [oracle_br] Migrando BD 11.2.0.4.0 para Forms 19.0.0.0.0
Blz ? Então, primeira coisa até onde sei no Oracle 11g ** absolutamente Não Existia ** um datatype nativo para JSON, vide https://asktom.oracle.com/pls/apex/asktom.search?tag=converting-json-data-into-oracle-11g Pra começarmos a entender a sua situação, plz nos explique QUAL datatype vc usou realmente nas tabelas 11g (provavelmente deve ter sido CLOB, já que um JSON nada mais é do que um texto), e COMO vc fazia a conversão/validação para JSON (no 11g provavelmente vc devia estar usando as packages do APEX, imagino)... Abraços, Chiappa Em sexta-feira, 15 de maio de 2020 14:39:44 BRT, Tiago de Assis Pimenta tiagopime...@ymail.com [oracle_br] escreveu: Pessoal, boa tarde, tudo bem ??? Na empresa que trabalho, estamos com esse projeto de migrar o database da versão 11.2.0.4.0 para 19.0.0.0.0, porém, estamos com alguns objetos inválidos, acredito eu, por causa do type JSON, que no 11 não era nativo e se não me engano, a partir da versão 12, já é nativo. Dei uma olhada em alguns docs da Oracle sobre a migração do database, mas nenhum ainda que eu vi, fala sobre as diferenças entre o JSON do 11g para o 19c Alguém passou por isso ? Ou que possa me passar o caminho das pedras ? - Dados do Ambiente - SO Desenvolvimento: Windows 10 64bitsPL/SQL Developer: 14.0.0.1961 (64 bit) Banco: Connected to Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0 - Um dos Vários Erros - Compilation errors for TYPE BODY BASE.JSON Error: PLS-00103: Encountered the symbol "." when expecting one of the following: ( Line: 80 Text: insert_value json_value := nvl(pair_value, json_value.makenull); Obrigado.
