Hi All,
     I have a table to the right, which is in a subform, which contains data that was inputted via a different part of the program, I want to show the data in the table within the sub form at this point it shows nothing but I know there is data in there.

Any help?

Paul D

[quote author=BOBSCOTT link=1181802834/0#1 date=1181830862]Is the data in the subform naturaly or relationaly linked to the main / parent  record you are looking at when no data is in the subform?

[/quote]


It is naturaly linked.

Hi BOBSCOTT
I under stand that, I think i might need to make myself a bit clearer, I want to enter data into a different Form (Merchant_Information), and not have to exit the app, and then go to another form (Plantrak) within the same database, and on that form contains the subform (Merchant_Information) which is in table form, and shows all of the data.


Thanks in advance.
Paul D

BOBSCOTT wrote on Jun 14^th, 2007 at 9:18pm:



Thats ok BOBSCOTT, thanks for the help I am going to read up on the "relational method" now

Paul D

drastixnz wrote on Jun 17^th, 2007 at 11:36pm:


We'll need more information: are you naturally or relationally linked? In either case did you enter some records in the subform? If so, where did you enter the data - with the subform "standalone" or with the subform appearing on its parent?

Yes there is

I want all of the data to be shown, I have used Natural links but the data does not show.

I enter the data into a form called Plan Tracking Log, I save the information and scroll past into a blank record.

Then I open another form (Plan Tak V0.2) it has "Plan Tracking Log" as a subform table in it the data does not show there.

drastixnz wrote on Jun 18^th, 2007 at 6:59am:

You will need to use "/=" in the key field on the main (parent) form, to see all the relational subrecords in the subform.

Just some background on this query to give more of an overview about the overall purpose of what we're trying to achieve (Drastix & I collaborate on some work and this is one of them)

"The Table View on the RH side of the page will show a Merchant Name, Merchant Reference, Job Number, Job Name, Job Address, Job Street & Job City. Because it is easier to overview and interpret the information in a table and because of the variety of quick searches we do, we've chosen this type of view and there are only 2 types of activities that can occur on this Table.

1) Select/highlight a record (and the resulting data for editing purposes is shown in a tabbed layout for the Merchant, or the Job Details, etc, on the lower LH side so that pull-downs, combo boxes et al are available plus good control of the data entering the database(s) is exercised) and
2) command buttons are available immediately above the Table View that changes the sort order of the records shown. eg. Default sort is by Job Number but it is also possible to sort by the name of the Merchant or by the Merchants Reference, Street, City, etc etc and the columns will shift depending on which is the primary sort order.
At no stage do we want to allow the user any data editing capability in the Table View even though this possible. We will program to stop that so that any data changes can only be done on the tabbed forms that relate to the record selected in Table View.

Just so you're aware, in the middle LH side of the screen are command buttons that restrict or expand which records will be shown in the RH Table View.

Each button that restricts records will change to a different colour when in force so the user is aware of what restrictions are, or not, in operation. This will allow multiple types of record selection criteria. They will operate on a toggle basis so they need to be clicked a second time to deactivate."

SRKTRY

"primary key field " is there any way that I need to set the field up to be the primary key field?

drastixnz wrote on Jun 19^th, 2007 at 7:21am:

Based on your previous post where you wrote "I have created a subform that is relationally linked and I used a common field which is record number", it sounds like you have already set it up. It's something that is done when you first create the subform in Designer. If you built it as a relational subform, you were required to specify the "Parent Record Field" in the Subform Settings dialogue box. You can view it now by opening the parent form in Designer, right-clicking on the subform and selecting "Subform Settings" from the mini popup menu.

Hello Carl,
I am sorry for the muck up, this is what I want.


I have a form called "Plan Track V0.2" within that form is a subform (Plan Tracking Log) which contains a table called "Plan Tracking Log".

I do enter the data into "Plan Tracking Log" via the Subform I enter it in at a different place, in the program.

When I open the form "Plan Track V0.2" I want the subfrom to show all of the data, that has been entered.

I am sorry for the misunderstading

Paul D

Carl Underwood quoted : Quote:


Paul hasn't coded for the restriction by months yet. He's working on just seeing the table filled up first, then will code for limiting whats seen

drastixnz wrote on Jun 19^th, 2007 at 9:17pm:


OK I believe you are saying you want every record to show from Plan Tracking Log in the subform no matter what record is showing in “Plan Track V0.2”

There is probably better and smarter ways to do this, I am sure the Lanticans or others will also chime in, but this should work for you.

Ad an element to Plan Tracking Log  named something like logKey.  Use logic to fill it with an X whenever a record is created. (one time mass updatate all existing records to have an X in this element)

Now

Ad an element to “Plan Track V0.2”    named PlanTracklogKey.  Use logic to fill it with an X whenever a record is created. (one time mass updatate all existing records to have an X in this element)

Open  “Plan Track V0.2”  and create a subform selecting Plan Tracking Log for the subform and select element PlanTracklogKey for parent record field and select logKey for child record field.

Now whenever you work with a record in “Plan Track V0.2” a match of the records will be found with every record in Plan Tracking Log and they will appear in your table view subform.

If you need any assistance in creating, updating or logic to fill the keys in the records let us know.

With Sesame there is always many ways to accomplish a task, this is just one method. I am not sure it’s a great method but until others chime in, it is an option.

To mass update existing records open the Plan Track V0.2”  Database in search / update mode with the command tree open. (Open the actual application not Sdesigner)

Press f7 f10 to select all the records

On the left hand side of screen on the bottom half of the command tree (I think it opens in default as sort) click the third arrow until it is on Mass update property.

click on PlanTracklogKey (or any element it really does not matter) to open the mass update editor.

Enter:  
PlanTracklogKey = “X”
Click on test to check logic
Exit editor

Click on the first down arrow and select run.
Select continue to have it all run or select interactive to do 1 at a time

Do the same thing for Plan Tracking log database using element log key.

This now set both key fields in all the records to be X

Your relational table subform will now work if it is set up correctly.

Now open Sdesigner to make all future record key elements  be x you will need to put logic like (example below) in both databases. (just switch PlanTracklogKey with log key)

If Not @isblank(your element name that proves you want to save this record goes here)

Then
     {
     PlanTracklogKey = “x”
     }


Hope this is somewhat clear. Let me know if I lost you somewhere.

Robert

Quote:


Just wanted to expand a little bit on what Carl said. Yes, Sesame does understand retrieve specs in the Parent key but the full family of retrieve spec options is not available to the Relational Link, i.e. functions like Min and Max will not work. The Relational Link does understand everything that is valid to put into a restriction spec. So if you just think of the Parent Key as a restriction spec as to what children it can display, you're gonna be on the right track. Restrictions are covered on pages 120-122 of the Sesame 1.1 User Guide in case anyone needs a reference.

-Ray

Paul D & SRKTRY,

If I correctly understood SRKTRY's explanation of what it is that you want to accomplish, your answer is in Sesame 2.0, which was just released over the weekend at the Sesame Users Conference.

My understanding is that you want a Table View subform AND a Form View subform of the same records, so that you can select the records you want to work with in the Table View subform, then have the Form View subform display that same record in order to take advantage of the more advanced layout elements. This approach has problems, like the fact that the record will be locked in the Form View subform, because the Table View subform will already have been the first to open that record. (And there are other issues which I won't get into now.)

In any case, I believe you may want to use the new Table View of your primary form (which can be activated automatically by programming) to display the list of records in a spreadsheet-type view. From there, you can click on a record, and then have a custom Menu Bar item that you can select to take you to the Form View of that record. From there, you can have a Command Button located on the form that would take you back to the Table View, if you wanted.

Both version 1.x and 2.x have Form View and Table View, but the Table View has been completely redesigned for version 2. It now shows the data in Table View formatted exactly the same as you have designed it to look Form View. That includes fonts, font sizes, foreground and background colors, formatting and alignment. Table View now also doesn't need to show ALL the fields/elements that exist on the form, you can have any subset OR all of them displayed in the table -- it's up to you. You can even save many various table layouts in saved Table Specs.

Version 2.0 has an additional 200 new SBasic Programming Commands! Sesame has taken an incredible leap in what can now be done with it.

Hello, people we both would dearly love to be in Baltimore to get version 2.0 and to meet every one, but being on the other side of the planet, it would cost a bit too much for us.

I am still working on this issue.

Quote:


Thanks Carl... Paul & I were not aware of the restriction with displaying the same data in both Table View _and_ Form View simultaneously but what we'd like to achieve still fits perfectly within that restriction.
Previously I mentioned that we do not want users to edit records directly in the Table View, only in the Form View so...

Do you have any code suggestions that will allow us to read the records in, based on the filters that may restrict what records will be visible (and refresh if any data changes, including new records) and display only in a table view (note the reduction in capitalised words to denote that this is a view that looks like a table but it is NOT Sesame's Table View) and have a button next to each visible record (lets say the max number of records visible in the tabled view is set at 20 ?) and when the button next to the record to be edited in the table view is clicked, that is the data that presents itself in the active Form View ?
At no stage do we want the user to even think that they can edit data within a tabled view but we do want them to be able to select, from that tabled view which record to edit in the Form data showing in the lower left of the screen.
To summarise... I think we only need to have the records in the tabled view as a "Read Only" per se.

drastixnz wrote on Jul 4^th, 2007 at 11:15pm:

Yes, there is a new programming commad called "@FormViewType", which will allow Sesame to know if the Table View is being viewed. If it is, programming could set all the elements to Read-Only. The user could then click on a custom menu bar command that will change the view to Form View, and programming could change all the elements to Writable.

Here is screen shot

Thanks for explaining, dave

YAAAA FIXED!!!!!


Thank you so much to the following people

SirKitry
Ray the Reaper
Hammer
BOBSCOTT
An Carl Underwood


Thank you so much for the help, each time I use this i learn more and more and more, i dont think I will stop learning,

Kind Regards
  Paul

Quote:


I know this is an old post...I'm curious about this too.  Is there a probelm, depending on what type of linking you have between  the parent and subforms whether you add or update data on the subform in standalone or with the subform appearing on the parent form?
I'm designing/redesigning a couple of appliocations and it would be wonderful to be able to enter/modify data with the subform on the parent form.

Hammer wrote on Oct 16^th, 2007 at 9:43pm:


I agree...better to take the direct route    Ok...let's "GOTO..."ummm...maybe not