sybase 15是否支持java中的bcp api？
很久以前，我发现 bcp 只是一个小 C 程序，它调用 sybase 客户端 api 的特殊位来将大量数据移入数据库。它以速度的名义进行欺骗、偷窃和跳过检查限制。 太好了，我完全赞成。 在 sybase 12 中，我注意到 api 在 C 客户端库中公开，而不是在 java 客户端库中公开。
我一直在寻找，但没有找到任何表明他们已经在 sybase 15 java 客户端库中实现它的内容。 有谁知道这在 sybase 15 中是否可用？
A long time ago I figured out that bcp is just a little C program that calls the special bit of the sybase client api to do mass data moving into the database. It lies cheats and steals and skips check constraints all in the name of speed.
Great, I'm all for it.
In sybase 12 I noticed that the api was exposed in the C client library, but not the java one.
I've been looking but I haven't found anything that says they've yet implemented it in the sybase 15 java client library.
Does anybody know if this is available or not in sybase 15?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不同意您对使用 BCP api 的 Java 的评论。虽然我同意 Java 和 ODBC/JDBC 的局限性，但这并不意味着使用 Java BCP api 没有优势。我们有一个包含大量 Java 的系统，从 Java 中退出并运行 BCP 命令行实用程序并不实际或非常有效。
运行命令行实用程序不会提供很好的错误报告和死锁重试。
它还需要将数据写入文件，这会增加操作数量并减慢整个过程。有时我们甚至无法在没有文件系统的网格上写入文件，并且 tmp 太小。
至于速度，JBCP 比原生 api 慢，但它是可以接受的，并且肯定比调用重复插入命令更快。
姆威利特（JBCP 作者）
I disagree with your comments on Java using a BCP api. Whilst I agree about the limitations of Java and ODBC/JDBC that doesn't mean there aren't advantages of using a Java BCP api. We have a system with a lot of Java and its not practical or very effective to shell out from Java and run the BCP command line utility.
Running the command line utility doesn't give very good error reporting and deadlock retries.
It also requires the writing of data to a file which is going to increase the number of operations and slow down the whole process. Sometime we can't even write a file as its on a grid which doesn't have a file system and tmp is too small.
As for the speed, well JBCP is slower than native api, however it is acceptable and certainly faster than calling repeated insert commands.
Mwillett (author of JBCP)
我不这么认为，这可能是将该操作纳入 JDBC 规范的更多问题。
我确实在 SourceForge 上看到了一个 JBCP 项目，但没有任何经验。
I am thinking not, it may be more an issue with fitting that operation into the JDBC spec.
I do see a JBCP project out on SourceForge, but don't have any experience with it.
如果您不介意 Java 程序不再可移植，您可以通过 JNI 链接到任何 C 库。这比必须重写您的应用程序或调用单独的任务来 BCP 数据更好，
我假设您不想用 C++ 重写整个应用程序；-)
If you don't mind your Java program not being portable anymore, you can link to any C library via JNI. That is preferable to having to rewrite your application, or to calling a separate task to BCP the data
I assume you'd rather not rewrite your whole application in C++ ;-)
答案是否定的。
但到底为什么要将大量数据从 Java 移动到服务器呢？ (1) Java 不是为此设计的，因此它会非常慢 (2) 本机 bcp 或 C+bcp 或 perl+bcp 或任何 shell 命令+bcp 都会在它周围尖叫，并无论如何都会替换它。这就像想要通过 ODBC 或 JDBC 运行 bcp 一样。
我们需要摆脱马斯洛的锤子，并使用正确的工具来完成工作。
进一步详细信息，回应评论：
连接到 ASE 服务器（客户端-服务器样式）的普通程序使用提供的 Open Client Library；这是本机的，可以有效地移动 TDS 数据包。连接件是通用的一英寸花园软管。用 C、C++、COBOL、Perl 和 PowerBuilder 编写的程序使用此传输。
ODBC（因此是 JDBC，因为它构建在 ODBC 之上）是一种使用一毫米软管连接到服务器的简单方法。虽然这对于使用 Excel 直接从 ASE 表绘制图表等任务来说已经足够了，但数据传输速度并不重要；对于移动任何大量数据、正常应用程序访问数据服务器来说，它是相当不够的（除非“程序员”不知道 [1] 可用这一事实）。
.
Java 没有 [1] 并且仅限于此 [2] 传输。
bcp 是一个由供应商提供的实用程序（独立存在），可以更紧密地连接到服务器。它不是“客户端 API 的特殊位”。不涉及“撒谎和欺骗”，所有约束均由执行任务的 DBA 指导。连接装置是一根两英寸半的消防水龙带，一般不向公众开放。它旨在快速移动大量数据。如果在与服务器相同的主机上使用，由于软管不是通过网络形成网状的，因此它传输数据的速度会更快。
很久以后，供应商将 bcp 功能作为库（用您的术语来说是 API）提供，因此可以从任何合理架构的编译器中调用。 C、C++、COBOL 和 Perl 都是这样，它们生成程序，因此可以直接从您的代码访问该库。连接是相同的两英寸半消防水带，但由于附加的层，它以两英寸消防水带的最大速度运行。
（希望这是一个完整列表的读者请注意：还有两个其他选项我没有在这里详细说明，因为它们是服务器-服务器并且与此线程无关）。
由于 Java 程序是目前仅限于与 ASE 服务器的一毫米连接，向 Java 提供 bcp API 是没有用的（您只有一根两英寸半的消防水龙带通过网络网状连接，流量为一毫米），它是一个荒谬的企业。这是有原因的，尽管有数以百万计的组织投入到 Java 中，但在其相当长的发展过程中，没有一个组织花钱提供一个可以移动的消防站。
你无法从腊肠犬那里获得灰狗的速度，给它赛道训练是没有用的。你可以停止在它耳边低声许诺。
其次，Java 无法有效地处理大型（源）数据集，它不是为此而设计的。因此，即使解除了 JDBC 的束缚（例如实现了原生 Open Client Library），它仍然无法像 C、C++、COBOL、Perl、PB 那样快速地移动数据；它将在一英寸软管中以滴流（四分之一英寸？）的速度移动数据。因此，即使如此，向 Java 库提供 bcp 功能也是荒谬的；如果 Java（在设计时考虑到其他优先事项）具有大数据传输能力，那么这将是值得的。
它可能有助于摆脱您的Java，Java，除了 Java 思维模式，并使用正确的工具（程序）来完成工作。如果您是一名 Java“程序员”，那么至少您需要熟悉您的编程语言以及可用库的功能和限制。最初的问题表明对此完全无知，因此我必须在修改后的帖子中提供它。
不局限于Java的程序员，思考大数据源位于哪里；最大限度地减少网络间的数据传输；考虑哪些程序已经编写并且可以使用（而不是与地球其他部分隔离地编写自己的程序）；并使用它们。
最后，为了理解，即使您确实在某些库中获得了 bcp 功能，并实现了它，当您将“程序”放置在现实世界中时，任何合理的 DBA 都会因其缓慢的数据传输速度而忽略它，并使用 bcp用消防水龙带代替。
The answer is NO.
But why on Earth would you want to move masses of data from Java to the server ? (1) Java isn't designed for that, so it will be very slow (2) native bcp or C+bcp or perl+bcp or any shell command+bcp would scream circles around it, and displace it anyway. It's like wanting to run bcp via ODBC or JDBC.
We need to move away from Maslow's Hammer and Use the Right Tool for the Job.
Further detail, responding to comments:
An ordinary PROGRAM that connects to the ASE server (Client-Server style) uses the provided Open Client Library; this is native, and moves the TDS packets efficiently. The connection is a universally available one inch garden hose. PROGRAMS written in C, C++, COBOL, Perl, and PowerBuilder use this transport.
ODBC (and thus JDBC because it is built on top of ODBC) is a simple method of connecting to the server using a one millimetre hose. While this is quite adequate for tasks such as using Excel to draw charts directly from ASE tables, where the data transfer speed is not relevant; it is quite inadequate for moving data of any substantial volume, for normal app access to a data server (except where the "programmer" is ignorant of the fact that [1] is available).
.
Java does not have [1] and is limited to this [2] transport.
bcp is an utility PROGRAM (exists on its own) supplied by the vendor that connects to the server much more tightly. It is not a "special bit of the client API". There is no "lying and cheating" involved, all constraints are directed by the DBA performing the task. The connection is a two and a half inch fire hose, not generally available to the public. It is designed to move large data volumes at speed. If used on the same host as the server, since the hose is not reticulated through the network, it moves data even faster.
Much later, the vendor made the bcp capability available as a Library (API in your terms), which can therefore be invoked from any reasonably architected compiler. C, C++, COBOL, and Perl are such, and produce PROGRAMS, and therefore provide access to this library directly from your code. The connection is the same two and a half inch fire hose, but due to the additional layers, it runs at a maximum speed of a two inch fire hose.
(Note to readers who expect this to be a complete list: There are two other options which I have not detailed here, because they are server-server and not relevant to this thread).
Since Java PROGRAMS are currently limited to the one millimetre connection to the ASE server, there is no use in providing the bcp API to Java (you will merely have a two and a half inch fire hose reticulated through the network, with a FLOW of one millimetre), it is an absurd enterprise. There is a reason why, despite the millions many organisations have poured into Java, during its rather long um progression, none of them have spent money in providing a firehouse that moves drips and drops.
You cannot obtain the speed of a greyhound from a dachshund, there is no use giving it racetrack training. You can stop whispering promises in its ear.
Second, Java cannot handle large (source) data sets efficiently, it was not designed for that. Therefore even if the JDBC strangulation was lifted (eg. a native Open Client Library was implemented), it still cannot move data as fast as C, C++, COBOL, Perl, PB; it will move data at a trickle (quarter inch ?) in the one inch hose. Therefore, even then, it would be absurd to provide the bcp capability to the Java library; that would be worthwhile if and when Java (which was designed with other priorities in mind) is annointed with large data transfer capability.
It may help to move out of your Java, Java, and nothing but Java mindset, and Use the Right Tool (PROGRAM) for the Job. If you are a Java "programmer", then at least you need to familiarise yourself with the capability and limitations of your programming language and the libraries available. The original question demonstrates complete ignorance of that, hence I had to supply it in my revised post.
Programmers who are not limited to Java, think about where the large data source is located; minimise data transfers across networks; think about what PROGRAMS are already written and that can be used (as opposed to writing their own in isolation from the rest of the planet); and use them.
Finally, for understanding, even if you did obtain the bcp capability in some Library, and implemented it, when you place the "program" in the real world, any reasonable DBA will dismiss it due to its trickle speed data transport, and use bcp with its fire hose instead.