I have a database that uses EventScript from Softwares for Humans (http://www.softs4humans.com/FMPro_Plugins.html) to create a new record after data is entered into a particular field.

The database is an inventory database that I use a barcode scanner with. The problem is that the database is slow to create the new record for the next scan, making the person scanning either have to slow down and wait for the database, or miss a few items because the database can't keep up.

Is there a faster plugin that will do the same thing for me, or are there other ways to optimize the database.

I know that EventScript uses calculation fields to work, which might have something to do with it, but it is a free plugin, which is nice.

Thanks

Darron

Hi

can you write the script that is fired by Eventscript ?

Case( Abs(Stock Count); Stock Count & S4HU_EventScript( Get ( FileName ) ; "NewRecord" ; "" ); 0)

The field is Stock Count.

The functionality is that an item barcode is scanned into the "Barcode" field. The scanner sends the carriage return signal, a lookup is performed in a related table for the item associated with that barcode, the cursor is placed in the "Stock Count" field and waits for a scan of a count number barcode. When the carriage return signal is sent this time, event script creates a new record, and the cursor is in the Barcode field again, waiting for the next scan.

Let me know if that didn't make sense.

Thanks

Darron

Ok

so Eventscript only fires a "New Record" script.

I don't think that this takes much time...

and if Yes, the problem isn't with the plugin, but with FM itself.

May be that is better to check the lookup ?

I suspect that your layout has some fields on it which are complex calculations.

Watch out for:

Unstored calculations

Calculations based on calculations, especially when unstored

The worst case would be a calculation based on a calculation, with unstored vales and summarising values from the whole file in all, or some, of the calculations.

Portals are also slow if sorted, and worse still if you are displaying calculations as mentioned above in each portal row.

When you finish editing a new/existing record FMP has to evaluate everything on the current layout, even if your entries would have no effect on the fields being displayed.

Test this by making a new entry screen with the minimum fields on show, i.e. "Barcode" and "Stock Count"

OK,

I am a newbie, so forgive my newbie questions.

But, I don't understand what an "unstored" calculation is vs a not "unstored" calculation.

Looking at the "Define Database" window, it shows that I have a total of 5 unstored calculation fields in this layout.

A screen grab of the "Define Database" window can be seen at http://homepage.mac.com/djeans/fmp/fmpdatabase.tiff

Can these calculations be set as not "unstored" and still have the same functionality?

Thanks

Darron

The unstored calculations are "unstored" because they are based on related fields - i.e. fields which are stored in another table/file. You cannot have these as STORED values (FMP limit) (it's an option on the STORAGE tab in field definitions)

The most likely culprit is "Stock count total" as it is SUMMARISING the records in a SUMming relationship set. The more records there are then performance will worsen.

Please TRY THE TEST I outlined - then you will know better.

Please also have a look at the FMP help system.

thanks for the explanation.

Do unstored calculations still happen if they are not on the current layout? Stock count total is used on a different layout than the main screen.

Thanks again.

Darron

Unstored calcs only evaluate when needed. As soon as you go to a layout with an unstored calc it is evaluated, including reporting etc.

Technically speaking unstored calcs remain unresolved until required.