Re: adVarWChar slower than adVarChar
- From: "Jeremy Lloyd" <xx.jeremy.lloyd.xx@xxxxxxxxxxxxxxxxxxx>
- Date: Mon, 28 Aug 2006 15:14:27 +0100
This isn't going to help solve the problem, but using VC++ and ADO we
recently switched our whole application to Unicode, including converting all
the database tables to Unicode. We did this for both SQL Server and Oracle,
and we cannot detect an appreciable difference in performance.
The application is pretty large (300+ tables). We do bulk data loads through
ADO as well as thousands of dynamic queries etc.
Basically there isn't anything fundamentally wrong with the technology.
Regards
Jeremy
"N. Scheller" <n.scheller@xxxxxxxxxxx> wrote in message
news:O7$4N1qxGHA.4232@xxxxxxxxxxxxxxxxxxxxxxx
Hello Bob,
thanks for your comment. Sure we can build a DTS package for each file to
be
imported for each of our customers. And we surely would find a similar
technology to do this in Oracle. But this would have to be adopted for
each
customer and for each kind of import file, so we are quiet convinced that
the import program we wrote is the best and flexible way (since we have to
check if a record already exists and update it or have to insert the data
if
the record is new) .
So back to my problem: is there any way to speed up the import with
adVarWChar parameters?
Norbert
"Bob Barrows [MVP]" <reb01501@xxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:%230Xlf2pxGHA.3496@xxxxxxxxxxxxxxxxxxxxxxx
N. Scheller wrote:
Hello experts,
I have some trouble with importing UTF files into a database:
the table in which I want to import the file contains a nvarchar(200)
field on SQL2000 and a nvarchar2 field in our Oracle-DB. We have
written an import program in VB which creates a stored procedure to
which all information from the text file is passed. The parameter for
the mentioned field has the same type as the field in the DB -
nvarchar(200) on MS or nvarchar2 on Ora.
Until last month, the import program used "adVarChar" to pass the
values to the SP:
cmdADO.Parameters.Append .CreateParameter(aColumnName(i),
adVarChar, adParamInput, 200)
Then we changed adVarChar to adVarWChar, since we had to import UTF
files containing special characters:
cmdADO.Parameters.Append .CreateParameter(aColumnName(i),
adVarWChar, adParamInput, 200)
Well, now we get the special characters properly imported into the
table. But the importing time for one file containing some thousand
lines increased from 8 minutes to more than 8 hours!!!
Changing back the parameter type to adVarChar, and we import the same
file in 8 minutes again.
Hmmm, it makes sense that double-width data would take longer to process,
but 8 hours seems a bit extreme ...
Since we have the same odd behavior on MS-SQL and Oracle, I assume
this is an ADO problem.
Any ideas?
Doesn't Oracle have some sort of functionality (analogous to DTS in SQL
Server) to allow data to be bulk-imported? I can't imagine DTS taking as
long as 8 min. for a little thousand-line file. ISTM that ADO is the
wrong
technology to be using for this task.
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"
.
- References:
- adVarWChar slower than adVarChar
- From: N. Scheller
- Re: adVarWChar slower than adVarChar
- From: Bob Barrows [MVP]
- Re: adVarWChar slower than adVarChar
- From: N. Scheller
- adVarWChar slower than adVarChar
- Prev by Date: ADO and VC++ in Visual Studio 2005
- Next by Date: JRO Compact/Repair not working anymore
- Previous by thread: Re: adVarWChar slower than adVarChar
- Next by thread: Re: adVarWChar slower than adVarChar
- Index(es):
Relevant Pages
|
|
