Outstanding script Help

[schnook]

HELLO ALL

WE HAVE A VESSEL LOG ON DATABASE THAT THE GENERAL PUBLIG CALL US AND LOG ON FOR THE DAY,

THE FIELDS THAT WE USE ARE

FROM = VESSEL REGISTRATION,

FISRT LOG IS A VALUE LIST THAT CONTAINS YES & NO,

CLEARED IS ALSO A VALUE LIST CONTAINING YES & NO.

NOW SOMETIMES A VESSEL CAN HAVE 4-6 ENTRIES FOR THE DAY

EG: WHEN THE VESSEL FIRST MAKES CONTACT FIRST LOG = YES, CLEARED = NO,

THEN ANY OTHER ENTRIES THAT THEY ARE NOT SIGNING OFF CONTAIN FIRST LOG = NO, SIGNED OFF = NO,

NOW WHEN THEY DO SIGN OFF FOR THE DAY FIRST LOG = NO, SIGNED OFF = YES

NOW WHAT I WOULD LIKE TO DO IS TO CREATE A BUTTON WITH A SCRIPT THAT WILL ONLY SHOW VESSELS THAT HAVE NOT SIGNED OFF, BUT ONLY THEIR LATEST ENTRY THAT SIGNED OFF = NO, IN A TABLE VIEW FORMAT.

CAN SOMEONE PLEASE IN DUMMY TERMS HELP ME WITH THIS.

WE ARE RUNNING WIN 7 WITH FMP ADVANCED 11

REGARDS

SCHNOOK

[Søren Dyhr]

To me is it clear that the two fields "First" and "Cleared" is in another table than the Vessel, due to the wording mentioning "4-6 entries" ... and from there is it to make the interaction between the two checkboxes via autoentering in the fields definition. All searches can then be made in the checkboxes table and the found set is then established by going backwards through the relation via GTTR(FS) ...

Find attached my first interpretation of the specs....

--sd

vessels.zip

[comment]

HELLO ALL

...

Please fix your keyboard, then re-post your message in a readable way.

[Søren Dyhr]

:yep:

[LaRetta]

Hi Schnook,

I see it a bit differently than Soren but I still think we lack information and other tables. I do not know if you have a Vessels table, if so substitute the second TO of VesselLog with your Vessels table (to isolate the ‘signed off’ vessels). I assume vessels are checked in and out multiple times in the log and the trips closed and other trips opened? VesselID #14, if it was checked out on the 16^th and not ‘signed off’ when returned on the 17^th and then checked out again on the 18^th and returned and signed off on the 19^th, system will see the vessel as signed off because it will see the single YES for this vessel. It will not see the prior ‘trip’. Can trips last more than one day because if not, the date can be included in the filter. If trips can last multiple days then we should consider alternatives, such as distinguishing one trip (within the log) from another.

Here is a script to achieve it if you only want vessels which have never been signed off (in the Vessel Log). Do you have a Vessels table? Do you have a Trips table? I would think the Trips table would hold details about the trip (where to, when, related table of people on board etc) and start/end dates(?) which would help us determine when a ‘trip’ vs a ‘date’ is finally signed off on.

Anyway, the attached file might give you some ideas on scripting it. Be sure to see the self join in the graph and the date sort at the bottom. :-)

VesselLog.zip

Edited October 27, 2011 by LaRetta

[Søren Dyhr]

Ah if thats the case, then should two lines of script, be all i takes - I've tweaked LaRettas template ...

--sd

VesselLogMOD.zip

[LaRetta]

Both of your ideas are very good!

Added ... personally, I will do just about anything NOT to add fields. I do not like adding table occurrences either but I see no other way to 'see across' other records in a table. If we knew how this solution were structured, it would help. If there is a vessels table?

Soren, it is wonderful to see you back on Forums!! I have missed you!! :laugh2:

[schnook]

Hi All

Sorry i have not received any of the post you guys have given your time to send me but i have not received any email notice of reply to my topic, i have turned on all email notifications in my setting hope this will fix it. Once again i am very sorry but i did not know email notification were turned off due to me having answers to past post sent to my in box.

Regards

schnook

[schnook]

Hi all

the layout (table) is called NEW RADIO LOG and all vessel are entered in this layout it is our daily log record, now some vessels can have 6-8 or morer entries per day and the radio operators would like to just click on a button to only show which vessels have not signed off.

We have 3 way their entries can look

first sign on for the day is: F/L = YES (F/L First Log) - S/O = NO (S/0 Signed Off)

if they call again during the day and do not sign off: F/L = No, S/O = No

now when they S/O: F/L = No, S/O) = YES

Hope this helps

Thanks for your time

schnook

[Søren Dyhr]

Both of your ideas are very good!

Added ... personally, I will do just about anything NOT to add fields. I do not like adding table occurrences either but I see no other way to 'see across' other records in a table. If we knew how this solution were structured, it would help. If there is a vessels table?

Soren, it is wonderful to see you back on Forums!! I have missed you!!

Would a CF do then, instead of adding fields as well as table occurences ... then I at least could indeed see across records - please scrutinize this attachment...

The CF is by the way this: http://www.briandunning.com/cf/497

--sd

VesselLog-2.zip

[Søren Dyhr]

first sign on for the day is: F/L = YES (F/L First Log) - S/O = NO (S/0 Signed Off)

if they call again during the day and do not sign off: F/L = No, S/O = No

now when they S/O: F/L = No, S/O) = YES

We have grasped this already, but would like to know the relational structure it should be part of ... or rarther would have known, since it can be done entirely independent of the relational structure using a CF instead ... if it then would be particular swifter than the relational approaches attempted earlier on in LaRetta's as well as my contributions is a question wholly dependent on the measure of data in processing.

--sd

[schnook]

Hi Soren

Sorry but i don't understand what you mean by (but would like to know the relational structure it should be part of) do you need a pic of my relationship table?

Regards

schnook

[LaRetta]

Hi Schnook,

A picture of your graph showing the connections of any other tables to this vessel log would help. We are particularly interested if you have a Vessels table (not the log but that holds one record only per vessel with a unique VesselID). If I recall, you want to make minimal changes to this solution right now. How large is the vessel log - how many records?

Hi Soren, I considered GetNthRecord() but can it not become very slow with larger record numbers or as the table grows? I like your new interpretation of 'fast summaries' technique!

[Søren Dyhr]

You're right, it might recurse endlessly, but isn't it just a tweak in the CF only to consider a fixed number of logggings within some sort of reason ... or designing the CF in the gist of this:

http://www.briandunning.com/cf/892

--sd

[LaRetta]

Maybe as a temp fix ... the real answer always lies with good structure not that I need to tell YOU that. Log entries do not log out - vessels do (or more specifically it seems), vessel trips do.

At least Schnook doesn't want spreadsheetish behaviors LOL! We could use Michael in this one; you are getting above my head with that second cf.

[comment]

We could use Michael in this one

Still waiting for the problem to be defined...

Edited October 29, 2011 by comment

[schnook]

Hi Guys

There in no vessel table all entries are created in the radio log and only show entries that are created for the day. As for vessel ID i think the only thing i have is the auto created record number, i have attached a zip file for you to look at if you need more info let me know. Thanks for your time and effort

database.zip

[comment]

Still waiting for the problem to be defined...

I guess that's not going to happen, so let me suggest a solution to a problem which may be similar:

1. Find the records for the date in question and sort them by Vessel;
   
2. Go to the first record and loop:
   

• Omit N-1 records (N being the number of records in the current group);
  
• If current record is a sign-off, omit it - else go to the next record.
  

[schnook]

Hello comment,

Sorry i didn't know you were waiting for me, what i need help with is a script that will omit vessels that have signed off for the day and show only the vessels that are yet to sign off.

What you have posted above is what need to be done but i would not know how to go about it.

Search for current date omitt entries that are signed off and show in table view the outstanding vessels.

Any help would be great in dummy tearms please. Thanks for your time.

Just asking is caps lock frowned upon when asking a question just like to know so as it does not happen again?

Regards

schnook

[Søren Dyhr]

Caps lock is frowned upon! ...and your upload is not working, due to unknown fileformat!

[comment]

omit vessels that have signed off for the day and show only the vessels that are yet to sign off.

No, that is a misrepresentation of the problem - and the source of the current confusion. You cannot omit or show vessels, because you don't have a Vessels table. The records you need to manipulate are log entries, and the problem is that a log entry doesn't "know" if it's the last entry for the day. So this cannot be achieved just by finding records.

Anyway, Søren already laid out the foundations and I have (hopefully) simplified it to:

SignOff.zip

---

All caps is considered SHOUTING - all across the Web, not just here.

[Søren Dyhr]

But I've meanwhile toyed a little with the CF and eventhough summaries have been around for ever and by this fact probably optimized pretty massively ... it's obvious that only current dates loggings have any bearings to the search at all. What I thought was that during such a day is there a max to how many calls to port possible at all, so a CF should only locate when the vessel id changes the first time after a sort. It's then a good question if the overhead to prevent endless looping in a recursive CF is taxing harder than having a genuine summaryfield, eventhough the CF resolves after just a few cycles?

--sd

VesselLog-3.zip

[comment]

Well, the way I look at it is: I don't need a (looping) custom function, and my script only loops once, so...

[Søren Dyhr]

But I'm merely reacting to a point made by LaRetta, to whom it's an issue not to litter a solution with extra fields ... being a summary fields or not.

--sd

[comment]

I don't think a summary count qualifies as "littering" - and I have a good reason to suppose LaRetta will agree:

http://fmforums.com/forum/topic/71836-getting-more-out-of-filtered-portals-in-version-11/page__p__339731#entry339731

On a more general level: there's always the question of how many resources to spend in order to get what you need. After all, the task in question could be achieved without adding anything to the structure, just by looping among all records of the found set. But that seems a bit too frugal even to a miser like me...

[LaRetta]

I'm not getting in it, LOL, I am still wondering why my first suggestion didn't just do the job right up pretty like ... :laugh:

[schnook]

Hi All

Thanks for taking the time to reply, have attached some screen shots that should open i did it from my MacBook last time this time from my pc.

I will have a look and try to understand what to do.

Have downloaded the zip files and have tried to play with the suggestions and add fields etc, but i can't change any thing in them, i need to be able to play to try and understand whats happening

Oh i won't shout any more didn't know that.

Regards

schnook

Sign On.zip

Extra Entry.zip

Sign Off.zip

Layout.zip

Relationships.zip

[schnook]

Hi Schnook,

I see it a bit differently than Soren but I still think we lack information and other tables. I do not know if you have a Vessels table, if so substitute the second TO of VesselLog with your Vessels table (to isolate the ‘signed off’ vessels). I assume vessels are checked in and out multiple times in the log and the trips closed and other trips opened? VesselID #14, if it was checked out on the 16^th and not ‘signed off’ when returned on the 17^th and then checked out again on the 18^th and returned and signed off on the 19^th, system will see the vessel as signed off because it will see the single YES for this vessel. It will not see the prior ‘trip’. Can trips last more than one day because if not, the date can be included in the filter. If trips can last multiple days then we should consider alternatives, such as distinguishing one trip (within the log) from another.

Here is a script to achieve it if you only want vessels which have never been signed off (in the Vessel Log). Do you have a Vessels table? Do you have a Trips table? I would think the Trips table would hold details about the trip (where to, when, related table of people on board etc) and start/end dates(?) which would help us determine when a ‘trip’ vs a ‘date’ is finally signed off on.

Anyway, the attached file might give you some ideas on scripting it. Be sure to see the self join in the graph and the date sort at the bottom. :-)

Hi LaRetta

Just need to clear up what you have posted in your attached file Is Vessel Log 2 a table occurance of the Vessel Log and i just change the field names to what i use in the scripts. Sorry been to busy with the new radio room to have a real play.

Regards

Alf

[LaRetta]

I was on project and had little time to keep up on this like I wanted.

Michael, you have a line commented out (smile) in your script on exit loop because of table name change. Soren, you really brought up some cool ideas to play with as well!

Hi Alf,

I suggest that you use the file that Comment presented instead of mine. It is only one script (no additional table occurrences or calculations) and, since he included fast summaries concept, it will be fast even with very large record set (I neglected to include that idea in my demo's loop).

[LaRetta]

But I'm merely reacting to a point made by LaRetta, to whom it's an issue not to litter a solution with extra fields ... being a summary fields or not.

--sd

I will do just about anything NOT to add fields. I do not like adding table occurrences either but I see no other way to 'see across' other records in a table.

That is what I said, Søren, and it still holds true for me. But when SOMETHING must be added to make a solution work, I would rather add a summary field (which I consider a flexible, multitask tool which can be used by ALL related tables in many configurations and filters) than a calculation or table occurrence (which are limited in use). I would add a value list first and foremost (but it would not help here).

So by adding a single summary field, we can indeed 'see across records' to count the vessel logs without another table occurrence by taking advantage of GetSummary() in the script.

ps I selected the fuzzy-faced person just because it looked strange. Maybe my pink, hairless self wanted some hair.

[comment]

Michael, you have a line commented out (smile) in your script on exit loop because of table name change.

Ah.

On the bright side, it works anyway - so you can simply delete the Exit Loop If[] step.

[LaRetta]

Alf, I said all it took was Comment's script but it will also take adding that (well-worth-it) summary field.

Michael, that is the third mistake you have made in 19,717 posts. Slacker...

[Søren Dyhr]

I would rather add a summary field

So would I ... I've just lost my bearings being off the tool for a while. It's strange that the sense of balance is the first to go awry - i would have expected a few holes in the rarity dept.

--sd

[LaRetta]

Søren, your mind for creativity has not slipped a bit. If being away from the tool caused a bit of a balance slip then just stick around. We like you here and you have contributed thousands of incredible ideas including a few on this thread alone.

And I miss your links and inputs... :yep: