DATA i/O gdl-addon - how much "performance" is lost query a big db_file.txt (10 mb)/lots of objects

[Anonymous]

Dear community,

I want to write a value of a couple of parameters from a db-data.txt file to gdl-paramters of special objects.

as an example:

there are about 5000 rooms (zone-stamps) in a ARCHICAD-project.
Their ID and some of their properties have been exported into a room-database-system.
In this (any third-party-system) there have been added/altered values to the zone-parameters of the rooms. These altered parameters and the ID then have been exported to the "db-data_file.txt".
Finally the "new" exported values come back into the objects (instances) using the "DATA I/O-gdl-addon"...
So far everything works fine and I hope it is a practicable solution to conect the two different systems without the need of developing a special I/O-apx for this use-case...

BUT I also wonder what will happen to a system or the archicad-teamwork project, when 5000+ zonestamps each query 1-5 parameters from a db-data-file which contains more than 5000 lines in 5-12 colons - i.e. 10 mbyte of txt-data?

Perhaps someone of you has already experience using the "DATA I/O-addon" in ths. of instances of gdl-objects in a archicad-procect.

Or perhaps even a member of gs-developer team can share experiance and knowledge about this topic - would be great

best regards from vienna,
stay well,
Yours Klaus

[runxel]

I have never dealed with this amount (and I think most people never have either).
But I'm wondering: Why aren't you using the Interactive Schedules?
I.e. export your IA as Excel, fill it with your external programm and read it back into AC.

The other way I'm thinking of would be a Master GDL (in the MVO) where a button resides and the stamps only query the database when a button in there is pressed (:

[Anonymous]

Thank you runxel for your reply.

Why aren't you using the Interactive Schedules?
I.e. export your IA as Excel, fill it with your external programm and read it back into AC.

Becaus in the quite complex workflow there is also a data-and-drawing export to dwg-cad-files. I have no problem exporting gdl-parameters into the defined attribute of a dwg-block instance...
BUT it is not possible to export archicad-properties to dwg-block-attributes...
Although the dwg-export is a mighty function some essential things always missed to get it work without artistic-workarounds...

This is (only) one of the pains in my ass when working in bigger building-data-managment envionments... (in this case about 5 mio. square-meters in thsds. of building-objects).

best regards from vienna,
Yours Klaus

[runxel]

catch17 wrote:
Thank you runxel for your reply.

You're welcome!

catch17 wrote:
BUT it is not possible to export archicad-properties to dwg-block-attributes...

Mh, are you sure? Maybe with a translator XML? Have a look at the German Forum, there was a similar topic a few days back.

[Anonymous]

Yes, sadly I am sure. Structured DWG-export is one of my main work. I am developing workflows for special data export from archicad to dwg the last years and this is one of the greatest disapointments. You can only export and convert gdl-parameters no archicad properties.

Yours, klaus

[Kristian Bursell]

I use GDL XML Extension extensively, and I have used the GDL Text I/O Add-on many years ago.
The speed in which the data is read is not affected greatly by the amount of data. However, the size of the file (mb) does affect how long it takes to open, hence you don't what to open and close the text file repetitively in one script run.
I have worked with very large amounts of data which I had to store in the objects in an array. If you are doing this then you need to know the limits of arrays which is somewhere just over 32,000 values. so if you have 5000 rows and 15 columns of data you want to store in the object (not just extract a couple values from a text file), then you will have problems. You only do this to disconnect the object from the data and hence require all the data imported into the object via a temporary connection; this keeps the object working a lightning speed even when using large amounts of data. Otherwise, every time the user interacts with the object it will read the data, this includes the 2D refresh when zooming and panning.