The thread is a little bit too old, but I wanted to put my $.02 seeing that not many have first hand experience w/ SDK.First of all, I developed a Bloomber line reader which was taking their real time data and pumping it into our analytics. So this is where I'm coming from and what my background is worth. 1. SDK support from Bloomberg is by email only. They are good in helping out and all, but turnaround time is there. (48 hours is their timeframe, although they are normally geting back in nder 24)2. The service is provided as is, meaning that if you have any problems whatever and call them up they are very helpful until and unless you mention that you are using SDK. At which point they promptly refuse to talk to you.This is understandable b/c they don't have enough qualified people to talk about serious matters on the phone, and also b/c SDK is kind of working agains't their business... The problem is that sometimes they have an issue w/ their server but since you are using SDK they might as well point a finger instead of looking into the problem. E-mail support is useless in this kind of a situation.3. BB API connection (which is what you get by using SDK) is somewhat unreliable when compared to DDE. You can easily test it for yourself w/ Excel, but I won't bother you w/ details. If getting the data in real time is not top priority you may be willing to live w/ this. It will also depend on the number of securities you are requesting, so YMMV.4. Lic. issues have been mentioned.So in other words, if BB SDK is the only option you will have to do what you have to do, otherwise, you may want to look around before jumping on SDK.like I said, my $.02

QuoteOriginally posted by: gotcpp1. SDK support from Bloomberg is by email only. They are good in helping out and all, but turnaround time is there. (48 hours is their timeframe, although they are normally geting back in nder 24)2. The service is provided as is, meaning that if you have any problems whatever and call them up they are very helpful until and unless you mention that you are using SDK. At which point they promptly refuse to talk to you.This is understandable b/c they don't have enough qualified people to talk about serious matters on the phone, and also b/c SDK is kind of working agains't their business... The problem is that sometimes they have an issue w/ their server but since you are using SDK they might as well point a finger instead of looking into the problem. E-mail support is useless in this kind of a situation.Thats not really true. Probably you haven't been writing to the correct people. If you are in the Asia-Pacific region, the main SDK guy at Bloomberg is Traveen Gulrajani, i think his bloomberg email is traveen@bloomberg.net - the SDK team for Asia-Pacific is based in Singapore, but they happily come to any country to give any amount of training. I haven't had any problem, always sent him an email and got replies within a day (sometimes 2-3 days, incase he is out and travelling). They are also pretty happy to share as many examples and codes as possible. When there is a server problem, then usually an error will come on the bloomberg screen like "GUY Director xxx.xxx.xx.xx is not responding" (etc) - it also means that the SDK won't work. As I wrote before in this post - "I have tried pulling some 100 stock's OHLC & V data for some 10 years at one shot on a P II machine with 128 M ram and then doing a huge amount of complicated operations on the data (trying to build an internal momentum indicator for an index) and it just took me less than 30 minutes". Frankly, I am sitting in a developing Asian country with low bandwidths and older systems - if you are in the US or Europe, your performance should be definitely better!! May be you need to relook at your code.

It is true that BB don't have sufficient resource, although they say this will change it see that as extremely unlikely.BB are a sales driven company, more so than 90% of the firms I deal with.SDK doesn't strike BB as a means to sales.They see the decision makers as a distinct set from SDK users, so whereas you can get responses to "user" queries froman informed person very quickly. Software stuff is just awful. It doesn't help that by its nature SDK support is harder. BB's commercial model doesn't allow for charging for consultancy, thus we have the problem of anything proviuded for free, it isa cost to be kept to a minimum.Their documentation is shameful, they come up with excuses like "it changes so often", or X bank didn't have problems when theydid it. On a one to one basis, their people are great, knowledgeable, and very helpful, however the "business" people hold sway, andtheir defintion of "business" is sales.

Don't know if anybody still interested in this thread. Anyway...What I've seen so far coding within the Bloomberg framework:-> If you planned to design some user interface and wanted to use the Bloomberg COM component and VB.net for real time data, forget about it. .Net framework is now forbidding (or trying to forbid) the use of the variant type in VB.Net. This type was extremely dangerous because it may stand for some undefined structure and handle any "normal" type from long to pointer. It was at the same type extremely useful because when coding you were not concentrating on the data type. Bloomberg COM API is unfortunately massively using this type for the returned event _data. So no way to use it anymore under VB.Net. But you can still code with VB 6 and wait for the next release of the COM component (which is not a priority according to their developement team). For the real time data I would be then really cautious if using COM API + VB.net. May work sometimes and sometimes fail which is not what a trading desk wants-> The C++ part of Bloomberg API is still working with C.net (of course). You can then get back to the basics and redesign what you want based on the C++ classes that are given in the C example (given in C++ 6.0 but still working under C.net). It is of course more painful but also more stable and I suspect that this part of the stuff based on "normal" types and pointers will keep on working in the future. The main problem is you got to understand the C++ asynchronous and event framework.-> When designing a database, watch out that all Blooberg requests can be slowed down at Bloomberg request if you are downloading too many data (too many is again decided by Bloomberg). Of course this sounds normal as they do not want you to devote all their resources only to your requests.

Very good points indeed.It won't be that easy for Bloomberg to fix either. It is not simply a job of being more rigorous on types, or just casting everything to text. The BB API does fun things with arrays as variants. Given that arrays in IL are inherent class types rather than lumps of memory, it would be possible to actually deliver a superior product.It will however be hard to retain backward compatability, MS hasn't managed that with VB itself.To make it worse, you've added to my dismay over BB's support for developers, and since they are phyisically unable to talk to anyone who isn't a trader the lack of .NET style features in Excel will keep their software far behind the curve.

What about the issues related to data provided in XML format? Now there are some spec's (not finished) related to descibed financial transactions/reporting in a standard XML format such as XBRL (see www.nasdaq.com/xbrl/), FinXL and so on.I guesss going down this route depends on when you will be rolling that App out. Now XML does not seem to be a reality, but in 6 months it may represent a very good solution? Self describing data (XML) and self describing functionality (Web services) with open standard seems a much less painfull route than proprietary API's.I have always found data consistency to be a nightmare. As soon as XML becomes the defacto standard with data providers, I will push XML all all App's because cleaning self describing XML data can be automated.Ben

Agreed, an XML interface would be ideal.Absolutely zero chance of Bloomberg doing it any time soon. They want cheap and cheeful interfaces that they can wave at traders. They simply have no interest in even talking to programmers.

A XML interface would be great,although bloomberg does not even mention it anywhere themselves, there is still hope. They are participating in defining mddl.Reuters even seems to have it already implemented in some way (regard the samples).Thanks for the additional replies by the way....ekke

QuoteOriginally posted by: DCFCAgreed, an XML interface would be ideal.Absolutely zero chance of Bloomberg doing it any time soon. They want cheap and cheeful interfaces that they can wave at traders. They simply have no interest in even talking to programmers.Hopefully, some time we can start replacing Traders with boxes. MIT Media Lab has some interesting work on software agent based markets. Ben

I don't think we're that far off. My guess is that the first purely electronic system will be market making. This can be done according to predefined rules, and some of it requires no knowledge other than the trade flow.