Submitted by vicente95650 on 2011/01/10 18:14
I finally decided to try InfoQube by importing my EccoPro data (a 14MB file). I had been looking for a front-end to a robust database (MySQL) that provided EccoPro-like functionality and when I realized that InfoQube used an embedded database instead,  I was somewhat disappointed.
 
I have been a continuous and very satisfied user of EccoPro since its debut many years ago,  and have had to deal with its limitations because I have not found a suitable replacement.
 
I was pleasantly surprised to find all my data was imported, including the structure.
I am still learning the user interface, but my initial impression is very good.
 
There was only one "glitch" that I could not explain :
 
1. some ecco sub- items (no top-level-items) appear twice in InfoQube,  and with the same EccoID.
They appear in InfoQube as a sub-item as they were in ,  they also appear as a top level item in InfoQube.
 
I have since read a posting in this forum that indicates this is a known bug in InfoQube.
 
InfoQube appears to offer some of the essentials of EccoPro that I cannot do without:
 
1 the outline view
2. the easy management of fields (or folders) for each record (item).
 
There are other aspects of  EccoPro that I consider essential and that I am as yet unsure exist in InfoQube:
 
1. robustness (this is the main reason I ended up with EccoPro in the first place).
2. ability to export both data and structure (I don't want my data to be enslaved by any PIM).
 
It appears at first glance that InfoQube does not expose some item fields that would be required  in order to export the structure (at least the parts of the structure that I consider essential) of the database:
 
1. parent iD of an item (there does exist a field that points to the value of the parent item but this is not very useful to me).
2. entry  order within siblings (I need to be able to preserve the order in which I entered items)
 
Can you tell me if there is a means to export data and structure or if such is in the plans?
 
Thanks you for a very useful and impressive program.
 
 
 

 

Comments

Hi Vincente
I cant help you very much as I'm a fairly basic user.
 
Here's one tip, from -- link to nonexistent node ID 2227 --
-
[quote=Pierre_Admin]
To help in the export process, you can extract the item main parent ID
 
To get the Parent ID, you can create a new number field:
  • name: IDMainParent
  • In options, enter:
    <Source>SELECT ¯Items.ParentID AS IDMainParent, ¯Items.ID AS ItemID
    FROM ¯Items;</Source>
[/quote]
Note: an item can have multiple parents - this will get the Main parent ID
 
Also,
you ask about entry order within sibling - would this not be covered by the ItemModified field (well, within IQ anways, this may not be enough elsewhere)?
 
Tom

vicente95650

2011/01/15 01:13

Permalink

Thanks for the reference. I will take a look. Sounds like this is the way to get the ID of the parent. My items currently have only one parent (because EccoPro does not support multiple parents).
With respect to the order of the siblings, I am interested in the order that the items appear in my view. In EccoPro I can re-arrange the order of items and EccoPro will maintain the order but does not expose any field (folder) that reflects that order.

 Hi Vincente,
 
Welcome to the IQ forum.
 
[quote=vicente95650]
I finally decided to try InfoQube by importing my EccoPro data (a 14MB file). I had been looking for a front-end to a robust database (MySQL) that provided EccoPro-like functionality and when I realized that InfoQube used an embedded database instead,  I was somewhat disappointed.
[/quote]
 
The interface can actually be used as a separate front end to any backend (IQ doesn't depend on Jet/Access)
 
It just needs to be configured that way... And it takes some time. I guess Pierre didn't invest the time as the need isn't/wasn't truly there and there are many other pressing matters.
 
That said, Pierre has been working on an SQL Server backend solution a while ago for a company. Not sure what happened with that. See there : -- link to nonexistent node ID 1358 --.
 
In any case, unless someone needs to have 10s of connections to the same DB and manage heavy loads of data, an SQL Server backend is probably not necessary -- even Access/Jet is overkill for a single user ! Not to mention that an SQL backend can actually be slower than Jet depending on the configuration etc.
 
[quote=vicente95650]
 There was only one "glitch" that I could not explain :
 
1. some ecco sub- items (no top-level-items) appear twice in InfoQube,  and with the same EccoID.
 
They appear in InfoQube as a sub-item as they were in ,  they also appear as a top level item in InfoQube.
[/quote]
 
Items aren't as rigidly structured in IQ. An item can have several links/relationships to other items, as a child or a parent. So it can appear as a TLI or as a child, no problem. It all depends on the filters set in the source bar (alt-s to display the source bar). Have a look at these sections in the manual :
 
[quote=vicente95650]
I have since read a posting in this forum that indicates this is a known bug in InfoQube.
[/quote]
 
It could be that you're experiencing the hierarchical bug where items, in full hierarchy mode, are seen both as TLIs and children.
 
For that bug to happen though, your items would need to all meet the grid's source.
It could be... But it's generally not the case, as in IQ by default only TLIs meet the source and sub items don't (or, more accurately : don't need to) -- they are displayed or not by using various filters. Sometimes though, especially if you use the inheritance option for a field, this default behaviour isn't the default one anymore.... And so items appear as TLIs when they shouldn't. I got used to that, it's a drag, and I filter these out using various strategies.
 
this bug will/should be fixed in a future version. Some modifications need to be made to filtering algorithm for that to happen.
 
[quote=vicente95650]
There are other aspects of  EccoPro that I consider essential and that I am as yet unsure exist in InfoQube:
 
1. robustness (this is the main reason I ended up with EccoPro in the first place).
2. ability to export both data and structure (I don't want my data to be enslaved by any PIM).
 
[/quote]
 
 
Could you expand on what you exactly mean by robustness?
 
As for the ability to export data and structure, it's true that it's somewhat limited at the moment. You can only use copy/paste (tab delimited option to paste in another db) and export as HTML. I guess you could include XML too, but it wouldn't be directly readable by another app. You'd have to write your own import tool... :)
 
More exporting options are on the roadmap though. Pierre can expand on the matter if he wishes to.
 
Regards,
 
A.

vicente95650

2011/01/15 14:17

Permalink

Hi Armando,
 
Thanks for your reply. I am glad to hear that the back-end database is Jet/Access and is not cast in concrete. The main thing I am interested in is that the database not be proprietary as it was in Eccopro.
 
Regarding the hierarchy of my items after import, I realize that IQ is more flexible, but I had expected that my existing hierarchy would be preserved upon import. It appears that IQ treated some of my items differently and I don't understand why. What did you mean by [quote=Armando] For that bug to happen though, your items would need to all meet the grid's source. [/quote] By robust database I mean one that makes it difficult for data and structure to be corrupted and has mechanisms to detect and repair corruption. I tried many PIMs prior to deciding on EccoPro and always ran into problems. EccoPro has been the most robust by far (provided I remain aware of its design limits).

Armando

2011/01/15 18:01

Permalink

[quote=vicente95650]
Regarding the hierarchy of my items after import, I realize that IQ is more flexible, but I had expected that my existing hierarchy would be preserved upon import. It appears that IQ treated some of my items differently and I don't understand why.
[/quote]
 
Maybe you could give us an example as it could be that what your seeing isn't "unpreserved structure" but just a different way of looking at it.
E.g : in IQ, it's possible to see any items in any given grid, in different order, depending on the chosen source and filters.
 
 
[quote=vicente95650]
What did you mean by [quote=Armando] For that bug to happen though, your items would need to all meet the grid's source. [/quote]
[/quote]
 
You can display the source bar by pressing alt-s (or  through the Grid menu).
At the leftmost part of the source bar, there's a text box : this is the  source. It can be simple (one field only), or more complex (2 or more fields with operators like "AND", "OR", etc. following the SQL syntax)
 
If all items -- Top levels or subs -- meet the source, some subs will have a tendency to show up as top level. The only way to prevent that is to either remove the data that make them meet the source, or change the source, or add some filtering criteria in the filter text box (center text box in the source bar.)
 
Have a look at :
or, more generally : Items, Values and Views
 
Note that the filtering UI and mechanisms will be reworked in a future version.
 
[quote=vicente95650]
By robust database I mean one that makes it difficult for data and structure to be corrupted and has mechanisms to detect and repair corruption. I tried many PIMs prior to deciding on EccoPro and always ran into problems. EccoPro has been the most robust by far (provided I remain aware of its design limits).
[/quote]

Access/Jet is very robust. Especially if you're the only one using it. It can be repaired etc.
It doesn't have that reputation, but that's because of faulty DB designs (not the DB backend per se... But  people blame the backend)  OR because it's used in context surpassing its capabilities (more than 20 simultaneous users... But It all depends on the kind of use each user makes of the DB, as jet's theoretical  limit is more around 255... ).
 
More on Jet, which has been used and many companies for more than 15 years :
 
And there are tons of articles everywhere, like :