When recently experimenting with the Business Objects ETL product Data Integrator [BoDi] (part of the Data Services suite), my college and I encountered some strange behavior when BoDi talks to an Oracle database.
Within BoDi a database is accessed through a DataStore object. This DataStore object is defined by a 'Connection Name' (e.g. an entry out of TNS Names), a user and a password.
Oracle makes use of schemas and schema owners (and rights of users on - part of - a schema).
So the user used within a DataStore definition must be configured within Oracle to have some rights within the database, and these rights are mostly limited to a subset of all the schemas present or even part of some schema.
Now when BoDi reads from 2 different schema's within the same database (by means of different users), the DataStore 'Connection Name' will be the same (it's the same Oracle database).
Because of this equal 'Connection Name', BoDi mistakenly makes the assumption that any of these 2 DataStore users will have visibility on each other schema content.
This is not necessarilly so! A user might have only visibility on a single schema.
But because of it's assumption BoDi will attempt to perform any join that is defined between tables of these 2 schemas in a single sql query (pushdown) to be performed by the database.
This is very nice performance wise as the join is performed by the database, but if the users do not have visibility on all used tables then this will not work.
There are some workarounds (e.g. forcing BoDi to make 2 select queries and performing the join itself - at a performance cost - by defining Aliasses on the DataStore).
[Although it's not clear to me what this Alias exactly does or is used for :-( ]
The workaround we've chosen is to use a single user that has rights on all schema's within a database so that the pushdown queries always work, gaining us the database performance.
Wednesday, April 15, 2009
Wednesday, May 21, 2008
Configuring mplayer to work with canopus codecs on Open Suse 10.3
A while ago I gave a presentation on the company document management system and the project that was going to extend it.
This was taped at the time and off course I wanted the video footage :-).
The footage was straight of the digital camera it seemed (2 files of 4 gig each) and no re-coding was done yet.
When I tried to play these video files on a default install of mplayer (MPlayer 1.0rc2-SUSE Linux 10.3 (i686)-Packman-4.2.1) with the full codec package (all-20071007) it failed to play. It seemed the needed video codec was not present.
A colleague told me the first couple of bytes of the avi file should tell me the encoding (and thus the video codec I would need for playback).
A 'head' of the video (avi) file gave me following output:
RIFF���?AVI LIST<�hdrlavih8@���#��8LISTt~strlstrh8vidsCUVC It appeared that "CUCV" (also given by mplayer) and "hdrlavih8" told me (via google :-) that I needed Canopus video codecs. Some google actions later I could get those video codecs here: http://codecsbox.com/download/codec/video_codecs/canopus_hq.htm
Of course it was a windows install file (which I thus dutifully installed on my windows machine).
Some further google told me I needed following files:
'cseHQa.dll', 'CSEUvec.dll' and 'CUVCcodc.dll', all located in 'c:/windows/system32'.
I copied those over to the default codec location of mplayer (/usr/lib/codecs).
Unfortunately no joy yet.
Mplayer did not yet know of these codecs.
Some more google learned I needed to add folowing section to the 'codecs.conf' file of mplayer.
So I downloaded the sources of mplayer and found a matching codecs.conf file there.
I copied that file over to the default config loaction for mplater: /etc/mplayer and added the above mentioned entry for the canopus video codec.
Now mplayer was finding the codec it appeared but could not yet load the needed above mentioned dll files.
Fortunately this was simple uppercase/lowercase problem. So copying the dll files to all lower case filenames got that solved quickly.
Now indeed the video rendered.
This was taped at the time and off course I wanted the video footage :-).
The footage was straight of the digital camera it seemed (2 files of 4 gig each) and no re-coding was done yet.
When I tried to play these video files on a default install of mplayer (MPlayer 1.0rc2-SUSE Linux 10.3 (i686)-Packman-4.2.1) with the full codec package (all-20071007) it failed to play. It seemed the needed video codec was not present.
A colleague told me the first couple of bytes of the avi file should tell me the encoding (and thus the video codec I would need for playback).
A 'head' of the video (avi) file gave me following output:
RIFF���?AVI LIST<�hdrlavih8@���#��8LISTt~strlstrh8vidsCUVC It appeared that "CUCV" (also given by mplayer) and "hdrlavih8" told me (via google :-) that I needed Canopus video codecs. Some google actions later I could get those video codecs here: http://codecsbox.com/download/codec/video_codecs/canopus_hq.htm
Of course it was a windows install file (which I thus dutifully installed on my windows machine).
Some further google told me I needed following files:
'cseHQa.dll', 'CSEUvec.dll' and 'CUVCcodc.dll', all located in 'c:/windows/system32'.
I copied those over to the default codec location of mplayer (/usr/lib/codecs).
Unfortunately no joy yet.
Mplayer did not yet know of these codecs.
Some more google learned I needed to add folowing section to the 'codecs.conf' file of mplayer.
>videocodec canopushqThe codecs.config file that is refered in the documentation of mplayer (on suse: /usr/share/doc/packages/MPlayer/DOCS/HTML/en/) is unfortunately not installed by default (default config location on suse: '/etc/mplayer') and mplayer uses the default internal config.
> status working
> info "Canopus HQ Codec"
> comment "http://www.canopus.com/canopus/technology/canopuscodecs.php";
> fourcc CUVC
> driver vfw
> dll "CUVCcodc.dll"
> out BGR24
So I downloaded the sources of mplayer and found a matching codecs.conf file there.
I copied that file over to the default config loaction for mplater: /etc/mplayer and added the above mentioned entry for the canopus video codec.
Now mplayer was finding the codec it appeared but could not yet load the needed above mentioned dll files.
Fortunately this was simple uppercase/lowercase problem. So copying the dll files to all lower case filenames got that solved quickly.
Now indeed the video rendered.
My very first blog post
A small step for humankind, but a large step for myself.
My very first blog post ever.
Going to have a laydown :-).
My very first blog post ever.
Going to have a laydown :-).
Subscribe to:
Posts (Atom)