Re: Sybase::bcp

The prepared statement should be pretty fast, though obviously not as fast 
as a non-logged bcp operation (however, as your table has an index you 
won't use non-logged bcp, so you're probably not loosing much speed!)

I'm still a little bit perplexed by that 1622 error, which would normally 
indicate a TDS error (i.e. an invalid packet sent to the server).

It would be interesting to see if you can generate this with the bcp 
binary - if possible you could create the load file (maybe by writing out 
the data to a file in your perl script instead of sending it to the 
server) and then loading that file via bcp ?
If that fails then there is a very valid reason to open a case with Sybase 
TS...

Michael





Internet
[email protected]@peppler.org - 14.02.2007 18:04
 
Sent by:        [email protected]
To:     sybperl-l
cc: 
Subject:        Re: Sybase::bcp

Hello Michael,

Thanks for your prompt reply. I took up your suggestion of using the BLK
api. This stopped the program from hanging. It did not however stop the
1622 error messages:
/
Message number: 1622, Severity 18, State 1, Line 1
Server 'myServer'
Message String: Type '7' not implemented./

In the end I decided to switch to using prepared insert statements..
probably not as good (?) but it served its purpose. I get the feeling
that a solution for a sybase 1622 error message might take a while to 
find.

cheers
Ed

[email protected] wrote:
>
> That looks like an ASE error, or possibly an OpenClient error. In any
> case I don't think that it is directly related to sybperl.
>
> On the other hand you are using the old DB-Library API - and you
> should probably use the new(er) BLK (ClientLibrary) API (i.e.
> Sybase::BLK)
>
> Have you tried the same data via the bcp tool ?
>
> Michael
>
>
>
>
> *I*nternet
> [email protected]@peppler.org - 07.02.2007 19:01
>
>
> Sent by:        [email protected]
>
> To:        sybperl-l
>
> cc:
>
> Subject:        *Sybase::bcp*
>
> Hello,
>
> I'm using Sybase::bcp to run in some data from a text file into an ase
> 15.0 express database. The database is on openSUSE 10.1. The table this
> data is being loaded into has an index that detects duplicate lines. The
> first file load enters the database with no problems. When I load the
> same file again, I expect to see a bunch of 2601's, duplicate row errors
> thrown by the callback function. Instead I see the following printed
> multiple times:
>
> /Sybase message 1622, Severity 18, state 2
> Type 'e2' not implemented./
>
> (Type messages include: ee,f1,ea,e4)
>
> *The perl script then hangs*. ????
>
> Inspecting the packets with tcpdump I know that communication has
> stopped between sybperl and the db. The test network is very simple,
> collisions etc are not a problem. The transaction logs (tempdb and the
> database in question) have plenty of space. I have not upgraded 15 to
> the 15.01 edition. Could that be it?
>
> I have loaded the file manually using bcp on the command line. And this
> produces the expected results.
>
> Now I am not sure whether this is a sybperl question or an ase
> question... if it is an ase question I will repost on ase.linux.
>
> Cheers
>
> Ed
>
> This message and any attachments (the "message") is
> intended solely for the addressees and is confidential.
> If you receive this message in error, please delete it and
> immediately notify the sender. Any use not in accord with
> its purpose, any dissemination or disclosure, either whole
> or partial, is prohibited except formal approval. The internet
> can not guarantee the integrity of this message.
> BNP PARIBAS (and its subsidiaries) shall (will) not
> therefore be liable for the message if modified.
>
>                 ---------------------------------------------
>
> Ce message et toutes les pieces jointes (ci-apres le
> "message") sont etablis a l'intention exclusive de ses
> destinataires et sont confidentiels. Si vous recevez ce
> message par erreur, merci de le detruire et d'en avertir
> immediatement l'expediteur. Toute utilisation de ce
> message non conforme a sa destination, toute diffusion
> ou toute publication, totale ou partielle, est interdite, sauf
> autorisation expresse. L'internet ne permettant pas
> d'assurer l'integrite de ce message, BNP PARIBAS (et ses
> filiales) decline(nt) toute responsabilite au titre de ce
> message, dans l'hypothese ou il aurait ete modifie.
>
>