May be i should clarify more on what i was wondering can be done or not.
we have our company data on Voyager Billing System software (by BCGI) and we use Impromptu Cognos to access this data and make reports out of it...
So when cognos impromptu can connect and access the data from the tables in the Voyager...i was wondering how to connect to the tables on the voyager software using ASP...
can this be done or am i totally going in the wrong direction...
Does the Voyager software use its own proprietary DB engine or is it backened by something like MS SQL or Oracle?
[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]
If it is proprietary, then unless you happen across someone here who has worked this out before, your best bet is to ask this question of the vendor.
[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]
Is there any other way i can achieve my task...i mean i want to give a nice front end using which the users can get the reports they want directly on the intranet....
Presently they send me the information with the constraints ( for eg: list of customers who deactivated their account on 09/05/2004)...then i make the report in cognos impromptu using these constraints and save it as an excel sheet and send it to the user...
here is the information given to me about the data at my company...
****************************
Data is currently housed in one of three places.
1. Voyager provides live data and history files on the following tables: Service Order History, Management History, Billing Financial Transaction, Sales, Sales Detail, Inventory, Call Detail Records, Equipment Summary for varying periods of time. (BCGI is providing an update of all tables, definition and relationships) Call detail record data is kept for 3 month, while other tables are archived for several years (since system conversion in some cases). This data is accessed via a “catalog” which resides on the Data server. When reports are run, the catalog retrieves the current or archived information from the Voyager Server.
2. For data fields that are not archived on Voyager, monthly reports are generated utilizing Impromptu’s Scheduler feature. These reports retrieve monthly data from the billing server and then store this data on the Data server. This information is stored in Impromptu [.ims] format. In this format, the data can be incorporated into new Impromptu reports. However there are limitations. One of the most significant limitations is our ability to consolidate, view and analyze month end data from multiple months. As will be discussed further, this is a result of each month end data file residing in a separate .ims file, as opposed to being in one database.
3. Data is also retrieved from the billing system in other file formats. For example, summary billing information is provided in a .txt format. This information is retrieved via Monarch and is then opened in Excel. Excel Pivot tables are created to summarize the data.
****************************
I would appreciate If you can shed more light on this.
This sounds like a big hairy mess. If I were tasked with this, then I would start by writing an interface layer for each of the storage media that you listed. Then I could create a nice pretty interface that would simply need to access the interface.
[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]
it looks like a mess to me also. So if i start considering to write an interface layer(as you mentioned) for the data on voyager how would i go about doing that...
and any other suggestions about writing the interfaces as you suggested...
Personally I would write the interface layer in VBScript, but that is just because I am comfortable with it. Anything should probably work.
Initially I would concentrate on one data source. Work on finding a way to access its data programatically. As I said before, the vendor is your best bet for help on this.
[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]
I would ask them first if their product supports any standard methods (OLE, ADO, etc). Best would be for them to send you an example. Even if it is in a language that you are not familiar with, it should point you in the right direction.
The goal of the data interface layer would be to make data access opaque to your user interface. So essentially you want to make it so that if the user interface wants a set of data, it asks for it the same way regardless of which data source the data actually comes from.
[red]"... isn't sanity really just a one trick pony anyway?! I mean, all you get is one trick, rational thinking, but when you are good and crazy, oooh, oooh, oooh, the sky is the limit!" - The Tick[/red]
We have a Snap Server ( i think it is basically a hard disk with no operating system ) with data on it...
What would be the best way to connect and retrieve data from it..
Do i need to export the data to some other database system(like for ex: SQL Server) before retrieving the data or can i directly retrieve the data from the snap server??
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.