VFE - Field is too small to accept data

[Kannan]

Amit,

In a ~TFM_INS table, when I include a number of timeslices in one cell (separated by ",") I am getting the following error while importing to VFE:  “The field is too small to accept the amount of data you attempted to add” (Please see the excerpt from the log).  Since ours is an hourly model, I have to define 'same' parameters for a group of timeslices.  Is there any limit for number characters per cell?  Of course I could work within the limit by defining data for each timeslice, but I will end up with a large number of tables! Is there any alternative to handle this?  Appreciate your help.

Thanks

Kannan

 

Version: 4.3.39

Model: TIMES LicType: VFTI

14.09.2011 14:12:52

Error while VEDA-FE: The field is too small to accept the amount of data you attempted to add.  Try inserting or pasting less data. In Procedure VEDA_FE.modcommonfunctions.ImportDataIntoTable_By_Query [194]

{-2147217833} The field is too small to accept the amount of data you attempted to add.  Try inserting or pasting less data.

[Antti-L]

While waiting for Amit's insights to this problem, here are some thoughts:

I think the maximum length of the field is 255 characters. Therefore, if your timeslice names are each 8 characters long, you can put there up to 255/9 = 28 timeslices separated by commas. So, even if you would have altogether 300 timelices, you would need only 11 lines to define the same parameter value for each and every one of them.

Interestingly, VEDA does not support using wild-cards for timeslices. If wild-cards would be allowed, you could use a clever naming system for the timeslices that would support easy defining of many different groupings by using wild-cards.

However, note that you can often make use of the inheritance mechanism, which is available for most timesliced parameters. That makes defining default values easy: The value specified for the parent timeslice is inherited by all timeslices below it, unless a value is explicitly specified for the child timeslice as well. Therefore, in many cases it is convenient to define the most common value by using the inheritance mechanism, and then define all the other different values directly at the individual timeslices.

It would be interesting to know what kind of timeslice groupings you use, and for what particular parameters you need to define the same value for such groups.

[Kannan]

Thanks Antti,

Yeah, the wildcards search doesn’t work for timeslice! 

We will have to define elasticity (COM_ELAST) for some commodities.  I think, we cannot use the inheritance mechanism as the price elasticity has to be specified at hourly level.  We have elasticity for peak and off peak time, though there is no variation at seasonal or weekly level.  So I have to specify ELAST at the hourly level.  In our case, each timeslice has 11 characters, inclusive the comma (e.g. FAL-SA-D06,FAL-SA-D07,….)

[Kannan]

Can I specify an annual elasticity and then implement values for off-peak timeslcies (about 8*4*3 timeslices)?  In such case, I can avoid large number of specification for peak hours.  

[Antti-L]

Well, COM_ELAST does support using the inheritance mechanism. So, to define the elasticity at the hourly level, you could define the elasticity at the ANNUAL or seasonal level, and these values would be inherited by all the hourly timeslices below those seasons. And then you could define a different elasticity for the off-peak timeslices at the DAYNITE level, like you said.

Maybe you could try and see if that helps?