I've searched and searched but found not documentation regarding creating a screen form for IBM INFORMIX-SQL Version 7.51.FC1XC. I've plenty of form examples but no documentation to tell me how to change these forms.
Many thanks in advance for some help in pointing me in the right direction.
Thanks,
Lloyd
General outline
It depends a bit on what changes you want to make. The starting point is the .per file, which is a plain text file that you can edit with any suitable text editor.
If you want to change the text on the screen, you edit in the changes you want, keeping the data fields between square brackets unchanged (in size, and usually in relative position).
If you’ve added a column to the table, you’ll need to add a new field for it at an appropriate place in the form with an appropriate field tag. You’ll also need to add the tag to the attributes section and identify the table it comes from, and add suitable field attributes.
If you need to add a new table or an extra screen, you have to work a bit harder, but you should be able to follow what’s already there for guidelines. Setting up joins etc requires an example, but the chances are you won’t need that.
Don’t under-estimate the value of generating a default form for a new table and then editing relevant information from that into the existing form.
$ sformbld -d temp-form-name stores extra_table
That gives you a temp-form-name.per file for table extra_table in the stores database.
If you're into (still useful) historical artefacts, you could look up Using INFORMIX-SQL, 2nd Edition by one Jonathan Leffler. It's only available second-hand. It's skewed towards Informix SE or Standard Engine (Informix Online was released the year before the 2nd Edition was published), but most of what it says still applies.
Documentation
There is documentation available on the IBM web site. Finding it is tricky. Nominally, the easiest starting point is probably http://www.informix.com, which will lead you to a relevant section of the IBM site. The ‘www.’ part matters; omit it and you go to a different, more general (and hence less useful) part of the IBM web site.
However, the referenced site makes it hard to find the documentation. I started at a different point, the IBM Informix 12.10 Knowledge Center. In the 'more information' section, I clicked on Download PDF Books, and from there clicked on links which lead to Publications for Informix 4GL. Once there, I select the 'Individual Publications, by Product and Version' link for Informix 4GL v7.50.xC5, from whence you can download:
Informix SQL Reference Manual v7.3
Informix SQL User Guide v7.3
Yes, there's no easy way around needing to know that the Informix SQL manuals are bundled with the Informix 4GL manuals, nor that Informix SQL is product separate from the SQL dialect of the Informix server, which might otherwise be termed 'Informix SQL'. Once upon a long time ago, it was correct to refer to INFORMIX-SQL or Informix-SQL as distinct from Informix SQL, but that got changed to suit marketers. It's also very subtle.
Related
Currently, there are a lot of old tables existing in framework model A in Cognos content store, we need rename these old tables to new tables(old tables structure are same to new tables, but their name are different) automatically, not manually, not by framework manager. Anyone has idea about it? could you share me? many thanks.
It would help very much if you clarify what the situation is. Your terminology is confusing.
The Cognos content store is the data base which stores everything which appears in the UI of Cognos Analytics. This includes the data source connection definitions, reports, and administration functionality like the memberships of groups and roles.
It is controlled by Cognos and you would very much like not touch it and alter it.
The objects in a Framework manager model are not stored in the content store. When you publish a package, the information in the package is written into the content store. Where is not something you should need to know.
My understanding about your question is this:
Some tables in a data base which is used in your FM model have had their name changed. You want to alter the model so that the model uses the new tables rather than the old ones.
There is extensive functionality in the FM UI to deal with cases such as the remapping to new source functionality.
It should be possible to programmatically alter the model.
The nature of the change of the tables is important.
If the nature of the renaming has been that you have changed the case of the tables from any of all upper case or all lower case or a mix of case table names and you have made them all lower case or all upper case and if you have 11.1.7 then you can use this utility.
https://www.ibm.com/support/knowledgecenter/SSEP7J_11.1.0/com.ibm.swg.ba.cognos.ug_fm.doc/c_fm_model_update_util.html
The utility does not have provision to specify a subset of tables to have their case changed. It will do the action on all of the data source query subjects. This might be a problem in your case.
2.
I have never needed to do this and, subsequently, do not know if this would really work but you could edit the action logs. This would entail looking through the metadata import actions and the modelling actions which refer to the tables which were renamed and editing them to refer to the new tables.
You would really need to understand the action logs.
For example, if you happen to have expanded the node in the UI for any of the tables, views, or synonyms when you did the metadata import, the action log will have decided to do an import of the list of the the tables ( or views etc.) of the data base. This happens even if you closed the node. If you didn't then the metadata import as captured in the action log will import every table (or view etc.) generically. This means that if a table has been added, the action log playback will import it and if a table has been deleted, then the action log playback will not fail because it could not find the table. Why such a state could ever happen is beyond me but that is what happens.
Do this on a copy. That should not be necessary to mention but you never know.
You would need to be absolutely sure that no-one decided that they were clever and manually edited the model.xml file. Manual editing does not get captured in the action logs.
You would need to be absolutely sure that no-one decided that they were clever and deleted some or all of the log files in the Cognos project.
You would need to be really really really sure that this is better than remapping. Frankly, the time invested in importing the new tables and remapping your model to use them would probably be less than the time invested in editing and then running the action logs, and then wading through the model to make sure you have not mucked things up.
Also, I don't know if editing the action logs is allowed in the licence so you could end up getting IBM mad at you.
I assume from your vocabulary that you are very new to Cognos...
The appropriate solution depends on how you define "a lot". Your Framework Manager model can be edited manually or by a program you write in C# or Java that leverages the Cognos Framework Manager SDK. Cognos SDKs are not trivial. There is a steep learning curve. In my experience, if "a lot" means less than a few hundred, you should do this manually. An experienced Framework Manager modeler could probably get through a hundred tables in an afternoon.
I'm quite new to Rails but in my current assignment I have no other choice but use RoR. My problem is that in my app I would like to create, connect and destroy databases automatically on user demand but as far as I understand it is quite hard to accomplish this with ActiveRecord. It would be nice to hear some advice from more experienced RoR developers on this issue.
The problem in details:
I have a main database (which I access with activerecord). In this database I store a list of my active programs (and some template data for creating new programs). I would like to create a separate database for each of this programs (when a user creates a new program in my app).
In the programs' databases I would like to store the state and basic info of the particular program and a huge amount of program related data (which is used to calculate the state and is necessary to have for audit reasons).
My problem is that for example I want a dashboard listing all the active programs and their state data. So first I have to get the list from my main db and after that I have to connect to all the required program databases and get the state data.
My question is what is the best practice to accomplish this? What should I use (ActiveRecord, a particular gem, etc.)?
Hi, thanks for your answers so far, I would like to add a couple of details to make my problem more clear for you:
First of all, I'm not confusing database and table. In my case there is a tool which is processing log files. Its a legacy tool (written in ruby 1.8.6) and before running it, I have to run an SQL script which creates a database with prefilled- and also with empty tables for this tool. The tool then processes the logs and inserts the calculated data into different tables in this database. The catch is that the new system should support running programs parallel which means I have to create different databases for different programs.(this was not an issue so far while the tool was configured by hand before each run, but now the configuration must be automatic by my tool) There is no way of changing the legacy tool while it would be too complicated in the given time frame, also it's a validated tool. So this is the reason I cannot use different tables for different programs, because my solution should be based on an other tool.
Summing my task up:
I have to crate a complex tool using RoR and Ruby 2.0.0 which:
- creates a specific database for a legacy tool every time a user want to start a new program
- configures this old tool on a daily basis to process the required logs and insert the calculated data into the appropriate database
- access these databases and show dashboards based on their data
The database I'm using is MySQL.
I cannot use other framework, because the future owner of my tool won't be able to manage/change/update it. So I have to go with RoR, which is quite painful for me right now and I really hope some of you guys can give me a little guidance.
Ok, this is certainly outside of the typical use case scenario, BUT it is very doable within Rails and ActiveRecord.
First of all, you're going to want to execute some SQL directly, which is fine, but you'll also have to take extra care if you're using user input to determine the name of the new database for instance, and do your own escaping. (Or use one of ActiveRecord's lower-level escaping methods that we normally don't worry about.) The basic idea though is something like:
create_sql = <<SQL
CREATE TABLE foo ...
SQL
ActiveRecord::Base.connection.execute(create_sql)
Although now that I look at ActiveRecord::ConnectionAdapters::Mysql2Adapter, there's a #create method that might help you.
The next step is actually doing different things in the context of different databases. The key there is ActiveRecord::Base.establish_connection. Using that, and passing in the params for the database you just created, you should be able to do what you need to for that particular db. If the db's weren't being created dynamically, I'd put that line at the top of a standard ActiveRecord model so that that model would always connect to that db instead of the main one. If you want to use the same class, and connect it to different db's (one at a time of course), you would probably remove_connection before calling establish_connection to the next one.
I hope this points you in the right direction. Good luck!
I am evaluating Microstrategy 9.0.1 and attempting to build a prototype metadata layer using its Architect tool. The tool doesn't seem to have any specific means to mark up joins in the way that the editing tools for SSRS data source views or Business Objects universes do.
How does this work in Microstrategy - I have never used this before and may be making invalid assumptions based on other systems I have seen.
If one does do this with MicroStrategy, how is it done?
You may also use the attribute editor, another (less graphical) tool used to create and edit attributes, their forms and relationships in hierarchies. This gives more fine-grain control over exactly how the attributes are linked to database tables and columns.
Joins can be done by dragging an attribute (Note you must create the attribute first) across the tables. The architect tool may or may not get the actual join columns right, but you can edit them in the properties panel.
I need to read from and write to Excel spreadsheets using Delphi 2010. Nothing fancy. Just reading and writing values from specific cells and ranges on different sheets. Needs to work without having Excel installed and support Excel 2007.
Some things I've looked at:
I've tried using ADO, which works OK for selecting everything in an entire sheet, but I haven't had much luck reading specific cells or ranges.
NativeExcel looked promising, but it doesn't seem to be in active development, and they don't respond to e-mails.
Axolot has a couple of products. The main product seems to be very functional, but is pricey. They have a lite version, but it doesn't support Delphi 2010.
Any recommendations? Free would be great, but I'm open to a commercial solution as long as it's reliable and well supported.
TMS Flexcel - I know it looks like a reporting component for Excel (which it does very well and is a very handy tool to have in your toolkit) but it also includes components for reading and displaying Excel files. I've been very impressed with how well Adrian Gallero seems to know the Excel API, including Excel 2007.
http://www.tmssoftware.com/site/flexcel.asp
Not free of course, but at 75 Euros I think it's good value.
I've had very good luck with ADO, provided the Excel sheet is a fairly straight-forward row/column layout.
The key with using ADO, I've found, is treating the Excel sheet like a database. If your Excel sheets are primarily straight row and column layouts, just treat the rows as database records and the columns as fields. Navigate to the desired row first by searching for a particular column (field) value (preferably something unique), and then read the desired cell in that row by referencing the field that is the column name.
If your Excel sheets are more free-form, then it will be more difficult.
Don't write off NativeExcel. I have used it for a couple of years now with excellent results. It's fast and versatile. I use it to produce a nicely formatted multi-page spreadsheet with frozen panes, formulas in cells, and data from a client's database for them to use for input and then send back to me. My clients were really thrilled when they got the first spreadsheet from me because it reduced their workload tremendously and it was fairly intuitive for them to use.
I don't know why they have not responded to you because I have updated their package at least a couple of time over the last two years. When my license expires, I definitely intend to renew.
I'd recommend SMImport / SMExport from http://www.scalabium.com
Mike has always been really helpful and quick to respond.
What really helps is if you have some kind of control over the layout of the excel file.
I have built a whole unit and acceptance testing framework where the data and the test controls are all contained within an Excel spreadsheet.
I did everything through ADO. You can restrict your ADO SQL query to a whole sheet, a named range or any range for the matter. In my opinion and experience, this method is very powerful.
Two things that did cause me some problems :
1. depending on how your sheets are named, ADO might or might not see them (again, if you have control over the layout, great !)
2. be careful about the data type ADO returns when you read data i.e. it might show numbers as strings. This is because ADO tries, IIRC, to guess the data type based on the first few rows.
Disclaimer : I have never used any of the tools mentioned above. ADO did the trick for me, and I feel more in control since I wrote the code for my framework (save the ADO part obviously...).
Bruce, I've used the Axolot XLSReadWriteII component for going on 10 years now. It's been very good, and their support forums (while lite on content) seem to be monitored pretty well. The XLSReadWriteII2 version is blindingly fast, and supports all sorts of things like charts and graphics, named ranges, adding formulas on the fly, cell formatting (including borders and shading, merging cells, vertical and horizontal alignment, auto-width column sizing, and so forth).
I haven't upgraded to the latest version (we're still using XLSReadWriteII2) because we can still use the Excel XP format files, and I haven't used the XLSMini at all. I can say really good things about the full product, though; in fact, I just used it for a couple of database export things this past week.
If you decide to go that route, I have a bunch of notes about how to do different things that might be useful; if you want them, drop me a note. I also have a Delphi 2007 app that just shows how to do different formatting and alignments; I actually reproduced an existing, fairly complex report in Excel complete with all of the formats, borders, etc. that I'd be glad to let you have as well.
DISCLAIMER: I have no connection with Axolot or any of their employees. I'm just a very happy customer who learned of the product at a previous job, and was impressed enough to buy it when I started my current one.
Don't bother with Axolot's XLSMini (lite) version. I haven't purchased either of them yet, but I asked about Excel 2007 support in early 2008 and Lars told me XLSMini was based on the XLSReadWriteII and that both would be updated with Excel 2007 support at the same time. XLSReadWriteII has had Excel 2007 support since April 2008; XLSMini still doesn't have it.
With great luck, I've used Axolot for some years now. The support forum isn't exactly brimming with messages, but maybe that's because it works so well?
You can use ADO connection string like
http://www.connectionstrings.com/excel
than include the options (in the third tab of ado connection string):
Extended Properties=Excel 8.0;HDR=Yes;IMEX=0
for security purposes Microsoft prevent modifications (with IMEX=1)
http://support.microsoft.com/kb/904953/en
Sample SQL (don't forget the brackets):
SELECT * FROM [Sheet1$]
The only thing you can't do, is deletion:
http://support.microsoft.com/kb/257819/en
So to delete a row make it empty!
You can also use SQL via ADO to export:
YourADOConnection.Execute('SELECT * INTO aSheet IN "'+ExtractFilePath(ParamStr(0))+'Exported.xls" "Excel 8.0;" FROM YourTable');
I would advise to go for an option where you don't need Excel installed on the machine. I once used a component that could easily fill in some data in one sheet without needing excel installed. I would also do most of the Excel work in the Excel sheet itself. And just use the components to fill in some data on the sheet.
My 2cts.
I believe several of us have already worked on a project where not only the UI, but also data has to be supported in different languages. Such as - being able to provide and store a translation for what I'm writing here, for instance.
What's more, I also believe several of us have some time-triggered events (such as when expiring membership access) where user location should be taken into account to calculate, like, midnight according to the right time-zone.
Finally there's also the need to support Right to Left user interfaces accoring to certain languages and the use of diferent encodings when reading submitted data files (parsing text and excel data, for instance)
Currently I'm storing all my translations for all my entities on a single table (not so pratical as it is very hard to find yourself when doing sql queries to look into a problem), setting UI translations mainly on satellite assemblies and not supporting neither time zones nor right to left design.
What are your experiences when dealing with these challenges?
[Edit]
I assume most people think that this level of multiculture requirement is just like building a huge project. As a matter of fact if you tihnk about an online survey where:
Answers will collected only until
midnight
Questionnaire definition and part of
the answers come from a text file
(in any language) as well as
translations
Questions and response options must
be displayed in several languages,
according to who is accessing it
Reports also have to be shown and
generated in several different
languages
As one can see, we do not have to go too far in an application to have this kind of requirements.
[Edit2]
Just found out my question is a duplicate
i18n in your projects
The first answer (when ordering by vote) is so compreheensive I have to get at least a part of it implemented someday.
Be very very cautious. From what you say about the i18n features you're trying to implement, I wonder if you're over-reaching.
Notice that the big boy (e.g. eBay, amazon.com, yahoo, bbc) web applications actually deliver separate apps in each language they want to support. Each of these web applications do consume a common core set of services. Don't be surprised if the business needs of two different countries that even speak the same language (e.g. UK & US) are different enough that you do need a separate app for each.
On the other hand, you might need to become like the next amazon.com. It's difficult to deliver a successful web application in one language, much less many. You should not be afraid to favor one user population (say, your Asian-language speakers) over others if this makes sense for your web app's business needs.
Go slow.
Think everything through, then really think about what you're doing again. Bear in mind that the more you add (like Right to Left) the longer your QA cycle will be.
The primary piece to your puzzle will be extensive use of interfaces on the code side, and either one data source that gets passed through a translator to whichever languages need to be supported, or separate data sources for each language.
The time issues can be handled by the interfaces, because presumably you will want things to function in the same fashion, but differ in the implementation details. To a large extent, a similar thought process can be applied to the creation of the interface when adjusting it to support differing languages. When you get down to it, skinning is exactly this, where the content being skinned is the interface, and the look/feel is the implementation.
Do what your users need. For instance, most programmer understand English, there is no sense to translate posts on this site. If many of your users need a translation, add a new table column with the language id, and another column to link a translated row to its original. If your target auditory contains the users from the Middle East, implement Right to Left. If time precision is critical up to an hour, add a time zone column to the user table, and so on.
If you're on *NIX, use gettext. Most languages I've used have some level of support; PHP's is pretty good, for instance.
I'll describe what has been done in my project (it wasn't my original architecture but I liked it anyways)
Providing Translation Support
Text which needs to be translated have been divided into three different categories:
Error text: Like errors which happen deep in the application business layer
UI Text: Text which is shown in the User interface (labels, buttons, grid titles, menus)
User-defined Text: text which needs to be translatable according to the final user's preferences (that is - the user creates a question in a survey and he can also create a translated version of that survey)
For each different cathegory the schema used to provide translation service is different - so that we have:
Error Text: A library with static functions which access resource files
UI Text: A "Helper" class which, linked to the view engine, provides translations from remote assemblies
User-defined Text: A table in the database which provides translations (according to typeID of the translated entity and object id) and is linked to the entity via a 1 x N relationship
I haven't, however, attacked the other obvious problems such as dealing with time zones, different layouts and picture translation (if this is really necessary). Does anyone have tackled this problem in a different way?
Has anyone ever tackled the other i18n problems?