David Robertson
Reputable Poster
RE: BSVW Table Joins
Hi Zoltán,
The procedure I used is the same as for importing foreign tables into OW I beleive, but basically:
1. Create a new table in OW, F55XXYYY, with all of the columns you require. You need to give it a file prefix in the creation process, and also define a primary, unique key. This does not seem to be important to the process, so just create something to keep OW happy.
2. Generate the file in OW.
3. Go to the appropriate enterprise server, and delete the index and file i.e. F55XXYYY_1 and F55XXYYY.
4. Start the apropriate interactive SQL feature, and CREATE VIEW F55XXYYY etc.. I renamed my output fields to match the column names I entered in OW for the table, but I don't know if this is required. A simple example of the SQL required is:
CREATE VIEW F55XXYYY AS SELECT aian8 as ccan8, aiclmg as ccclmg, abalky as ccalky
FROM F03012, F0101
WHERE aian8=aban8 AND aico<>'00000' AND (abatr='E' OR abatr='C')
5. Back to OW, and create a new BSVW, something like V55XXYYY, over the dummy file F55XXYYY, including all columns.
6. Generate the view.
7. You can now use the V55XXYYY as the input BSVW for UBE's and APPL's.
8. Moving to Production. Haven't done this yet, but I plan to deploy the dummy file and the view, repeat the processes 3 and 4 above, then generate the V55XXYYY view again in Production.
I also added attachments to the OL for F55XXYYY and V55XXYYY, so that the next poor developer has a chance at figuring out is happening. I think it is also very useful to copy the CREATE VIEW SQL statement into the attachment, so that you can regenerate if you need to.
Also, I now have no F55XXYYY_1, but OW does not seem to be bothered by this.
David Robertson
[email protected]
WorldSoftware A4.1 to A8.1
OneWorld B7a to B733.3
All O/S's, All DB's
Regards,
David Robertson
Mobile: +44 (0)7799664342
Fax: +44 (0)
Mailto
[email protected]
Webpage: http://David.Robertson.net/
Hi Zoltán,
The procedure I used is the same as for importing foreign tables into OW I beleive, but basically:
1. Create a new table in OW, F55XXYYY, with all of the columns you require. You need to give it a file prefix in the creation process, and also define a primary, unique key. This does not seem to be important to the process, so just create something to keep OW happy.
2. Generate the file in OW.
3. Go to the appropriate enterprise server, and delete the index and file i.e. F55XXYYY_1 and F55XXYYY.
4. Start the apropriate interactive SQL feature, and CREATE VIEW F55XXYYY etc.. I renamed my output fields to match the column names I entered in OW for the table, but I don't know if this is required. A simple example of the SQL required is:
CREATE VIEW F55XXYYY AS SELECT aian8 as ccan8, aiclmg as ccclmg, abalky as ccalky
FROM F03012, F0101
WHERE aian8=aban8 AND aico<>'00000' AND (abatr='E' OR abatr='C')
5. Back to OW, and create a new BSVW, something like V55XXYYY, over the dummy file F55XXYYY, including all columns.
6. Generate the view.
7. You can now use the V55XXYYY as the input BSVW for UBE's and APPL's.
8. Moving to Production. Haven't done this yet, but I plan to deploy the dummy file and the view, repeat the processes 3 and 4 above, then generate the V55XXYYY view again in Production.
I also added attachments to the OL for F55XXYYY and V55XXYYY, so that the next poor developer has a chance at figuring out is happening. I think it is also very useful to copy the CREATE VIEW SQL statement into the attachment, so that you can regenerate if you need to.
Also, I now have no F55XXYYY_1, but OW does not seem to be bothered by this.
David Robertson
[email protected]
WorldSoftware A4.1 to A8.1
OneWorld B7a to B733.3
All O/S's, All DB's
Regards,
David Robertson
Mobile: +44 (0)7799664342
Fax: +44 (0)
Mailto
Webpage: http://David.Robertson.net/