External Database Checkbox

[Matt Binder]

IrriCad Team,

A situation that we have here at Netafim Australia is that we create a new database each year with a new database extension name. As you would know IrriCad will always look for it's original database externally whenever a project is opened which can be painful in our case if we are to open an old design or on another level another IrriCad users design. Question: Can IrriCad automatically default to only it's internal database?

What I am proposing (as per attached) is a external database checkbox to be added to each hydraulic item menu. In a default state the checkbox will be unchecked and if items are to be added or changed they can only come from previous items that are currently in the design or in other words, the internal database. Once the box is checked, a seperate tile appears on the menu asking as to which database the hydraulic item is to come from. This would eliminate the messages that appear when IrriCad cannot find the database in which it was originally created with. If an item is added with the same properties from the external database as the internal database a message will appear on the screen asking the user if they would like to continue. The Plot Template would get it's data and colours from the internal database also.

I would like to hear your and other IrriCad users feedback on this as to whether or not it would be something to consider for the future.

Kind Regards,

[Dan Crosby]

Matt,

When Irricad cannot find the original database for a design, it should prompt you to find it. At that stage you can always point the design at its own internal database (if you want to modify it), or just cancel, and when prompted tell Irricad to stop trying to update from the current database (provided you just want to look at it). The only time this would fail would be if you have a database in the original location, with the original name that is not, in fact, the original database for the design. Once a design is pointing at its internal database, you can save it to stop the messages reappearing.

We could perhaps have an option to automatically use the internal database if the external one cannot be found, but we certainly would not want to have the ability to specify a database per item. That would inevitably lead to utter chaos!

Note that you can 'restrict' a design to the current items it contains (the internal database) at any time by going to Settings|Irrigation - Design Specific and changing the component database to point at the internal database.

Dan

[Kosi Kalogerinis]

Good Morning Dan,

I may be off on a tangent here, but feel free to shoot me down

What I see is that every design has it's own internal database. It would be much simpler and less room for error when sending designs around, for that particular design to only refer to the internal database by default.

For instance let's say I wanted to work on a design that was sent to me by John Citizen. For this example I will make it simple. This particular design has 100mm, 80mm & 50mm PVC Class 6 as submain. If I wanted to add more 100mm in certain sections, I would go to zone pipe, and from the drop down box select 100mm PVC Class 6. This drop down box should only list the items from the jobs internal database..

Now where the external database could come into it. Let's say I wanted to add 40mm PVC Class 6 submain. This is an item which is not in the current design. I would now then go to zone pipe, then I would select "use external database" to which then all items selected in the external database are now displayed in the drop down box. This is where I would then select 40mm Class 6 PVC. Now that the 40mm has been added to the design, when saving this design the 40mm Class 6 PVC is now added to the internal database. In other words when adding items from the external database, this item should be merged into the internal database.

I could then send this design back out to John Citizen and he would then by default have the 40mm included in the internal database that travels with the design.

We really haven't had a group discussion about this over here, however to summarise what we are saying is that Irricad by default should always refer to it's internal database at all times for everything, and ONLY refer to the external database when ADDING items that are not found in the internal database.


Kosi

[Kosi Kalogerinis]

a big bump, this would truly save us time.

[Gennaro Vellotti]

This is my view on the database only. Couple of points:

1) What you are suggesting Kosi, is how the WCADI, database works. I believe that this has been put forward in the past to Irricad.

2) I personally like better the way currently Irricad operates the database, on a number of counts. Once you get your head around what its doing, then there should not be a problem. As per Dan's suggestions, there are many ways to deal with it. I have no problems with the way it currently operates.

This debate has been had before, but going to an internal, or selecting an external is always giving up the ability to check for changes that have been made, which was a downfall of the other design software.

I like the way Irricad tells, me when a database item has been changed. This is important especially when there is an error in a item or it has been accidentally updated or needs to be updated.

[Kosi Kalogerinis]

Thanks for throwing a different light on that Gennaro.

I understand that if there was a technical error with an item in the past, it can be fixed by way of updating the database - however this is the only benefit isn't it? What about when we have 50 items to update every time we open up an older design? This takes alot of time, and after all time is money

What is clear is that what may be suitable for some users may not be suitable for others, and the fact that it has been raised in the past shows that there is some merit into exploring this further.

[Gennaro Vellotti]

Hi Kosi,

Yes I agree, it was brought up in the past, but the reason it was brought up, was human nature, that we were happy with what we know, and that was the other software method. I am the first to admit that, but now that I know the software better and it is in my comfort zone as well as the other software, my preference is for Irricad to leave the database as is.

Perhaps, you need to look into why you are creating so many different databases?

With ARCGIS it uses databases and drags items into it just like Irricad, except, when someone has changed a bit of data then it up dates in your plan, yet it doesn't flag it (which I don't like). Plan gets finished sent to client, then client tells you, hey thats not right please fix/correct it. Time = Money = Client

Glad to sit with you and give you some examples, when your in the office next.

[phil]

I have to say that I'm with Gennaro and really not in favour at all of adding an extra check box to the hydraulic item dialogs. In the majority of cases it adds an unnecessary level of complexity - ideally we want the internal database to be transparent to the user.

One thing to note is that we did add an "inexact match" feature when updating items from the internal database (have a look at the readme.txt item 11) in the 10.50 notes). This helps when items in the external database differ by description or warehouse code only. We could also perhaps add another option for a more inexact match (i.e match on hydraulic parameters only).