Нужен проверенную компанию в сфере ж/д логистики? Железнодорожный оператор ERWSV — то, что вам нужно!
Официальный сайт ERWSV
#ERWSV #железнодорожныеперевозки #логистика #вагоны
 
Реализуем проектную и промышленную логистику:
Организация проектных перевозок
Промышленная железнодорожная логистика
#проектнаялогистика #промышленнаялогистика #железнодорожнаялогистика
 
Перевозка грузов крытыми вагонами — надёжная защита груза:
Грузоперевозки в крытых вагонах
Предоставление крытых вагонов
Оборудование в крытых вагонах
Всё о крытых вагонах
#крытыевагоны #арендавагонов #грузоперевозки
 
Полувагоны для насыпных и навалочных грузов — выгодные тарифы:
Перевозка грузов полувагонами
Полувагоны в аренду
#полувагоны #насыпные #навалочные #аренда
 
Аренда ж/д цистерн — специализированный состав:
Нефть по ж/д
Керосин цистернами Беларусь
Цистерны аренда
#цистерны #нефтепродукты #нефть #керосин #наливные
 
Фитинговые платформы — для 20- и 40-футовых контейнеров:
Перевозки на фитинговых платформах
Предоставление платформ
Платформы под заказ
Универсальные или специализированные платформы
Особенности ж/д платформ
[url=https://erwsv.com/bl

Ищете проверенную компанию в сфере ж/д логистики? Компания ERWSV — ваш выбор!
ERWSV Rail Service
#ERWSV #железнодорожныеперевозки #логистика #вагоны
 
Организуем логистику под ключ:
Организация проектных перевозок
Промышленные ж/д перевозки
#проектнаялогистика #промышленнаялогистика #железнодорожнаялогистика
 
Перевозка грузов крытыми вагонами — для промышленных товаров:
Грузоперевозки в крытых вагонах
Предоставление крытых вагонов
Перевозка промышленного оборудования
Всё о крытых вагонах
#крытыевагоны #арендавагонов #грузоперевозки
 
Перевозка полувагонами — широкая сеть маршрутов:
Перевозка грузов полувагонами
Предоставление полувагонов
#полувагоны #насыпные #навалочные #аренда
 
Аренда ж/д цистерн — профессиональное сопровождение:
Нефть по ж/д
Керосин цистернами Беларусь
Аренда цистерн для нефтепродуктов
#цистерны #нефтепродукты #нефть #керосин #наливные
 
Перевозки на платформах — крупногабаритная техника:
Фитинговые платформы
Фитинговые платформы в аренду
Платформы под заказ
Как выбрать ж/д платформу
Перевозка крупногабаритных грузов
[url=https://erwsv.com/bl

Hi

Uniqueidentifier in Cognos is specific to Framework Manager and is used to tell Cognos that the field will be used in joins and in conjuction with Determinants, Cognos will generate the appropriate SQL accordingly. Uniqueidentifier ca work with Numeric, Character etc. but that being said MD5 Hash may or may not work because it is considered unsafe and broken. MD5 also cannot be entirely binary because it can contain alphabets too during it's generation. 

Uniqueidentifier in databases refers to a varchar type of field (GUID - Globally Unique Identifier) which is globally unique across the database, not across the table. While this is good for data integrity but it's really bad for the performance of the query because of it's size.

Depends on where you want to apply this. Outside of modelling in FM, you can definitely use the MD5 field in a hand written SQL to join the Fact and Dimension tables. Hand written SQLs do not face limitations of the Cognos versions

As the title says, I'm wondering if Cognos version 12+ supports binary fields as key fields between tables?
For example, an MD5 hash is used as the primary key to join the fact and dimension tables.
What about uniqueidentifier types instead of binary?

Hi @deetchiga ,

Is the issue solved, can you please let me know the reason?

Regards,
Sreeni.

Hi @dougp

Tried that too still same issue.

Regards,
Sreeni.

On the command line you use to call trigger.bat, have you tried putting quotes around the password?

Hi All,

We have setup trigger concept in our cognos vm, when we try to test it fails with below error:

Tried things:
1. Changed password from special characters to plain password(alpha numeric)
2. Tried service account tagged to system admin role
3. Also scheduling and run with options capability explicitly defined for sys admin.
4. Same service account able to login from Cognos UI.
5. Tried individual user access same below error.

So basically when we try to trigger it using trigger.bat we are facing this issue.

Please provide your thoughts.


AxisFault
faultCode: Client
faultSubcode:
faultString: CM-REQ-4342 An error occurred with the client.
faultActor:
faultNode:
faultDetail:
{http://developer.cognos.com/schemas/bibus/3/}exception:
<severity>error</severity>
<errorCode>caf</errorCode>

<ns1:message><messageString>CM-CAM-4005 Unable to authenticate. Check your security directory server connection and confirm the credentials entered at login.</messageString></ns1:message><ns1:message><messageString>CAF-WRN-2082 An error has occurred. Please contact your administrator. The complete error has been logged by CAF with SecureErrorID:2026-03-03-05:07:49.245-#25</messageString></ns1:message>

CM-REQ-4342 An error occurred with the client.
at org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:222)
at org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:129)
at org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1087)
at java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:610)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1718)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2883)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:534)
at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:888)
at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:824)
at java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
at java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
at java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:635)
at java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:324)
at org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:698)
at org.apache.axis.Message.getSOAPEnvelope(Message.java:435)
at org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
at org.apache.axis.client.Call.invoke(Call.java:2443)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at com.cognos.developer.schemas.bibus._3.ContentManagerServiceStub.logon(ContentManagerServiceStub.java:8165)
at Trigger.login(Trigger.java:111)
at Trigger.main(Trigger.java:276)

Thanks for sharing your knowledge. That makes sense because Cognos would generate the SQL based on the recent version and every version of every programming language has some changes in the way it gets compiled by the compiler and subsequently executed by the database. I have spent quite a bit of time comparing the SQLs generated for the same report in different versions and found some changes.

I think the reports should be upgraded as a best practice, to inherit the newer features and to prevent them from stop working. 

My experience has been that report upgrades are typically not needed.  But I like to get new features -- like moving from 10 to 11 and enabling interactivity -- so that my users can have more streamlined workflows.  I also converted as much as I reasonably could from CQM to DQM to prepare for a possible move to the IBM Cloud.  One thing I have found is that any of these upgrades can cause problems.  Reports must be reviewed.  In my environment, with 12,000 reports, 3000 distinct users total, 250 distinct users per day, and hundreds or thousands of report runs per day, I let users do the "testing" in the normal course of their duties.  This works for me because I find that most report problems can be corrected quickly.  (Keep in mind that this is in the context of system upgrades.  Naturally, if we're making database changes, reports get tested before inflicting them on users.)

One thing I have seen -- and I think this relates to DQM -- is that performing multiple layers of calculations in a query can get a little sketchy.  An example is if you create a data item that summarizes another data item that is calculated from a third one that is sourced from an upstream query and use it as a filter.  While this type of thing worked flawlessly for years, I have found that some are failing in recent Cognos versions.  The solution is to break the steps into separate queries (Query1 -> Query2 -> Query3) to get the aggregation correct at each stage.