téléchargement de grandes colonnes de la base de données via odbcJ'ai une colonne SQL varbinary (MAX).Il semble que la largeur de colonne pour JMP soit de 65 536, je ne peux donc pas télécharger la colonne entière. Cela ne semble pas être un problème uniquement ODBC.
Actuellement, je les fais un par un en récupérant simplement les sous-chaînes jusqu'à ce qu'elles soient toutes vides et en les concaténéssant dans un tableau.
Cela prend une éternité.
Quelqu'un a-t-il des suggestions sur les moyens d'optimiser cela ?J'essaie d'éviter d'utiliser python/sqlcmd/etc. pour récupérer les blobs directement (en évitant JMP).
Accès aux donnéesRe : télécharger de grandes colonnes depuis une base de données via odbcOui oui.Très appréciée.
Re : télécharger de grandes colonnes depuis une base de données via odbcJuste une note que cette limitation fait semblent avoir été supprimés dans JMP16.1. Merci!
Re : télécharger de grandes colonnes depuis une base de données via odbcOpe, c'est ma faute.Ça ira. Merci.
Re : télécharger de grandes colonnes depuis une base de données via odbcBonjour, @vince_faller .
Ce problème aurait dû être résolu dans JMP 16.1. Veuillez envoyer un e-mail à l'assistance si vous avez testé cela dans la version 16.1 et constatez toujours le même comportement.
Re : télécharger de grandes colonnes depuis une base de données via odbcRebonjour @Dahlia_Watkins , des nouvelles si cette demande de fonctionnalité a eu du succès ?
Re : télécharger de grandes colonnes depuis une base de données via odbcMerci @Dahlia_Watkins
Quelqu'un sur Internet sait-il s'il existe un moyen de forcer la taille à indiquer dans la transaction ?
Mon implémentation actuelle est extrêmement lente (abonnement par groupes de 65 536 et concaténation jusqu'à ce que le plus long soit pris en charge) et je ne suis pas autorisé à changer de pilote ; donc je suis un peu dans le pétrin.
Re : télécharger de grandes colonnes depuis une base de données via odbcPar bryan_boone le comportement est dû au fait que ces pilotes ne réajustent pas la longueur de la colonne. Par la suite, JMP définit une longueur par défaut de 65536 lorsque ces données ne sont pas fournies.
J'ai ajouté une nouvelle demande de fonctionnalité pour augmenter cette valeur puisque JMP peut gérer ces données.
En attendant, l'utilisation de SQL Server (natif) semble fonctionner.
Re : téléchargement d'une base de données de grandes colonnes depuis une base de données via odbcOuais. En utilisant exactement la même chaîne de connexion.Re : téléchargement d'une base de données de grandes colonnes depuis une base de données via odbcAh ok. donc puisque j'utilise VARCHAR(MAX), peut-être qu'il n'y a pas de longueur de colonne ?
Malheureusement, même avec le bloc récupéré, cela ne fonctionne pas.
Re : téléchargement d'une base de données de grandes colonnes depuis une base de données via odbc@vince_faller ,
Utilisez-vous le même pilote ODBC pour Python et JMP ?
Stan
Re : téléchargement d'une base de données de grandes colonnes depuis une base de données via odbcPouvez-vous essayer d'utiliser :
Preferences( ODBC Disable Block Fetch( 1 ) );
Parfois, le pilote ODBC ne signale pas la longueur de la colonne.
SQL Server est l'un des pilotes prenant en charge la récupération de bloc (ce qui est beaucoup plus efficace qu'une ligne à la fois), mais si la longueur de la colonne n'est pas indiquée par le pilote, la valeur par défaut de 65 536 est utilisée.
Re : téléchargement d'une base de données de grandes colonnes depuis une base de données via odbcCela dépasse ma capacité à tester pour comprendre ce qui se passe.
@briancorcoran ?
Re : téléchargement d'une base de données de grandes colonnes depuis une base de données via odbc@Jeff_Perkinson
En regardant cela de plus près, je ne peux pas expliquer ce comportement.Je suis capable d'obtenir des valeurs exactement de la même table et de la même chaîne de connexion via Python.Pour une raison quelconque, JMP efface la colonne dès qu'elle atteint 65537.
Names default to here(1);
driver = "ODBC Driver 17 for SQL Server"; // using SQL Server
server = "localhost";
database = "Test";
username = "sa";
password = "REDACTED";
cxn_string = "DRIVER="||driver||";SERVER="||server||";UID="||username||";PWD="||
password||";Database="||database;
cxn = create database connection(cxn_string);
executesql(cxn,
"
CREATE TABLE [dbo].[LargeChar](
[LargeCharID] [bigint] IDENTITY(1,1) NOT NULL,
[SomeBigChar] [varchar](MAX) NOT NULL,
CONSTRAINT [PK_Blob] PRIMARY KEY CLUSTERED
(
[LargeCharID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
"
);
executeSQL(cxn,
"INSERT INTO [LargeChar]
VALUES('"||REPEAT("A", 100000)||"')"
);
dt_download = executeSQL(cxn,
"SELECT SomeBigChar
, SubString(Convert(VARCHAR(MAX), SomeBigChar), 1, 65536) AS Char65536 -- this works
, SubString(Convert(VARCHAR(MAX), SomeBigChar), 1, 65537) AS Char65537 -- this doesn't
FROM [LargeChar]",
"This should work?"
);
show(length(dt_download:SomeBigChar[1]), // full text doesn't show
length(dt_download:Char65536[1]), // text that is only 65536 shows
length(dt_download:Char65537[1]) // text that is one higher? nope
);
//execute SQL(cxn, "DROP TABLE [LargeChar]");
close database connection(cxn);
//Python script returns
/*
0 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
Name: SomeBigChar, dtype: object
0 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
Name: Char65536, dtype: object
0 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
Name: Char65537, dtype: object
*/
Y a-t-il quelque chose qui me manque ?Ou peut-être que sous Python ajoute des fonctionnalités.
*EDIT* désolé pour tant de modifications.J'espère que vous ne recevrez pas d'e-mail pour chacun.
Re : téléchargement d'une base de données de grandes colonnes depuis une base de données via odbcTRÈS pertinent.Ma faute.Il se passe alors quelque chose de bizarre.
Merci @Jeff_Perkinson ,
Re : téléchargement d'une base de données de grandes colonnes depuis une base de données via odbc
@vince_faller a écrit:
Il semble que la largeur de colonne pour JMP soit de 65 536, je ne peux donc pas télécharger la colonne entière.Cela ne semble pas être un problème uniquement ODBC.
Je n'ai pas d'idée immédiate sur votre enquête réelle, mais je souhaite clarifier la déclaration ci-dessus. La largeur maximale d'une colonne de caractères dans JMP est BEAUCOUP plus grande que 65 536.
New Table( "untitled 15",
Add Rows( 1 ),
New Column( "repeat",
Character,
"Nominal",
Formula( Repeat( "a", 128000000 ) ),
),
New Column( "length",
Numeric,
"Continuous",
Format( "Best", 12 ),
Formula( Length( :repeat ) ),
)
)
Je suis sûr que ce détail n'est pas pertinent pour résoudre votre problème de vitesse/requête et j'ai peut-être mal compris ce que vous vouliez dire par largeur de colonne .
