TM1 Forum

Hi all,

doesn't the function "TM1SystemBuildNumber" returns the build number of the client instead of the server as mentioned in the API Documentation?

Returns a string corresponding to the build number of the TM1® server.

Cheers,
Martin

MartinBrandl wrote:Hi all,

doesn't the function "TM1SystemBuildNumber" returns the build number of the client instead of the server as mentioned in the API Documentation?

Returns a string corresponding to the build number of the TM1® server.

I haven't used that function (I'll test it in the morning if I have time since I do have some clients in a mixed environment) but I can't see why you would think so. Bear in mind that the only place that the API code is used in conjunction with a standard TM1 client (and even then it doesn't have to be) is when you use it to construct VBA code in Excel.

However I use it in, for example, an Access database as well as in a couple of stand-alone VB applications. In those there is no TM1 client, other than the application that I've written using the API. And the API can't access the build number of my client application, even assuming that it has one. (Which obviously the code running under Access won't, other than the version of the Access application itself. The API certainly won't be able to access that version number, because it won't even know that it's running inside the Access IDE.)

Hi Alan,

I am developing a TM1 driver in C++ for an ETL-Application and don't use any TM1 clients like Perspective.

TM1SystembuildNumber does return the build number of the local client API (tm1api.dll) rather then the TM1 server version - as mentioned in the API documentation.

Cheers,
Martin

MartinBrandl wrote: I am developing a TM1 driver in C++ for an ETL-Application and don't use any TM1 clients like Perspective.

TM1SystembuildNumber does return the build number of the local client API (tm1api.dll) rather then the TM1 server version - as mentioned in the API documentation.

Oh dear. I'm afraid that you appear to be correct, though I can't test this with the current version since I don't have a 9.5.2 version which uses different servers and clients.

The API version number is supposed to be returned via TM1SystemVersionGet (which, just for the sake of consistency (not), returns an integer rather than a string). TM1SystemBuildNumber and TM1SystemBuildNumber_VB (both returning strings) are supposed to return the server version according to all of the documentation. However when I tested it against a 9.0 server using 8.2.12 API dlls (and, obviously, the TM1SystemBuildNumber_VB function) the answer I got was "8.2.12.1940".

I'd suggest reporting this as a bug. I don't know that you'll get anywhere, but I'd suggest doing it anyway. I can't, because they won't even listen to any request that mentions 9.0 any more.

(Your conversation with support, imagined version:
Support: "Oh, that's a bug in the documentation. We'll change the documentation to fix it in a few years. Maybe."
You: "Hang on, how can it be a documentation bug? If that was the case then TM1SystemVersionGet would be redundant."
Support: "Aaaahhh..."
You: "So how DO I get the server version?"
Support: "Sorry, you can't do that. Would you like to log it as an enhancement? We can add it as the 9,746th item that we'll look at."
You" "What are the first 9,745?"
Support: "Varying the transparency and shades of colour of toolbars and graphs in web reports."
You: "ALL of them???"
Support: "Well no, just the first 9,000 or so.")

OK, so I have an active imagination but I don't think I'm far off the mark there. My guess is that somebody screwed up. I'd bet that when they were testing it they tested it with the same client and server version and consequently got the result that they were expecting, without realising that it happened to be from the wrong source.

Hi Alan,

your reply saved my day
Thanks for confirming the wrong behaviour of "TM1SystemBuildNumber".

Cheers,
Martin

Alan Kirk wrote:I'd bet that when they were testing it they tested it with the same client and server version and consequently got the result that they were expecting, without realising that it happened to be from the wrong source.

I think you're right, after all they'll be testing a new client at the same time. From what I've seen of their regression testing (or lack of) doing something different wouldn't have even entered their minds.

I hope with the delay of TM1 10.1 that this trend has been bucked. After all this is first major version release under the IBM stewardship.

I hope with the delay of TM1 10.1 that this trend has been bucked. After all this is first major version release under the IBM stewardship.

I hope so too.