Portal Problems

[cmc2000]

I have db oF checks . many checkwriters have multiple checks with images. I want to be able to view all the checks and histsory, like paid amount, promise to pay, comments, and the actual check images for each person. I'm guessing a portal is what i need, but i could use some help on setting it up and getting the format and scripting correct.

Thanks

 

[marty1452]

A portal is used to display and sort data from the existing database or a related database. The sort comes from the relationship you need to define to install a portal.

To do this you need a Client database and a Check database.

The client database has a Client ID, unique and not changeable.

The Check.fp5 database has a Check ID, unique and not changeable and a f_Client ID field. The f_ indicates to a programmer that it is a foreign ID field or in other words, an ID field coming from a different database.

Check.fp5 database needs a least a Check container field, maybe a date paid field, and what ever else that would be exclusive to the check, not the client. The Client.fp5 database has in it all of the Client only data.

Now while in the Client.fp5 database, go to file, define relationships, and select a new relationship. When writing these, it's surprising how many you can create in a solution so a good rule of thumb is create a name that help identify what is does. Something like this: Client ID|Checks. Then you can see the connection the relatioship is making. The first selection in the creation of your relationship is the client id field. Next select the Check.fp5 database and then the f_client id field.

This relationship causes only the data that matches the client id to show through our relationship. The check database if you look at it by itself is it will contain hundreds on checks. The client and f_client id matching will reduce the display of the data down to the one or two check you are wanting displayed in the client file.

Next in your layout, select the portal tool and draw a portal. The dialog will ask for a relationship for the portal and you will select the relationship that you previously defined. Next drag a field onto the portal and you should be sure the relationship is the defined relationship and select the check container field. The portal can be configured to display 1 or many lines and the size and shape of the portal is user changeable.

I hope this helps.

Marty

 

[cmc2000]

Thanks for the help, that help me understand the process alot better, I now have a checks BD, and a checkwriter DB, check DB has image, date, amount of check, check number, check Id, and f_clientID. My checkwriter DB has all check writer personal info plus clientID.
NOw when I went to define the relationship in the checkwriter DB, i did as you suggested, i'm wondering where i get the data for the f_clientID field which is on the check DB, how do i make them match up? I have unique serial field on the checkwriter database client ID field. I'm just not sure what to put in the f_clientID so that for each person, all their checks show up in the portal.

 

[marty1452]

Write a script that looks something like this:

Enter browse Mode
Copy Client ID
Perform External Script(write a script in the check file)
go to field(xxx)


Check Script
Go to layout(XXX)
Select(f_client id)
Paste
Go to field)XXX

Now you have a choice here. Do you want to design a screen to input this information or edit this file from the portal.

The script could return you to the original file. To do this requires the go to field(xxx) in the first script and not in the second one. To edit in the check DB omit the go to field in the first script. Note about scripting, the script will run top to bottom. It pauses so to speak, to run the external check db script. When that script is finished, the original script starts where it left off. That's why having a command go to field(xxx) after the perform external script will keep you on your original page. You will see the screen refresh with this script and should never see the check db screen.

The client id and the f_client id fields must by on the layout to use copy and paste. The field id's aren't pretty on a layout so I usually pick a spot that all of my id's are on my layout, make them 1 px by 1 px to hide them. Also note for copy paste to work you have to have the field set as modifiable.

One more thing about id's. Each record in each database has it's unique ID. The f_id's can be numerous and multiple databases are linked together. Do compromise the unique id's. If you are linking a client id with 5 other databases, each will have it's own unique id plus the client id as a point of reference and sorting.

I hope this helps.

Marty

 

[lebisol]

just a thought:
copy---paste is not needed....relational DBs....lookups...or calculation field= ::some_other_field

 

[marty1452]

I was thinking about your solution. Design limits when I began programming was in my mind from lack of seeing what could be. I haven't seen your solution but I imagine what it could look like.

Rather than work with a portal inside another database, design the navigation system that seamlessly switch the user from one display to another.

An example of this is at

http://www.ask-max.net/maxinstall10.exe.

Click on the Finance tab and then Borrower Details. This is where your client information goes. Notice the portals on the bottom right. Notice the name of the database on the top left. Now click on the Purchase tab. Notice the name of the database now. As you can see it's a seamless blending of many databases but as the user, it looks like only one. The purchase tab in your solution would represent the checks.fp5 database. This concept could help your design process. The portal is used for a snap shot but the details are on under the purchase tab.

Marty

PS You must enter something in the company information to run.