Best way to store big amount of data

Hi, i need to store a big amount of data, written in a txt its size is almost 12 mg, anyway it depends on the computer it runs, beacause what i want to store is all the shared files in a computer.
Which is the best way to store it? Array string? textfile? List? I don�t need the data after the app close.
Thanks

Well, then which is the best solution? LinkedList or
Tree? i only need to store the full path.
What i didn�t say, my fail, is that i need to search
for a file name once i have stored them...For searching, LinkedList will be very slow if it's very large. I think the same is true of javax.swing .tree.DefaultTreeModel, which is the JDK's only tree implementation. I don't know what Jakarta-collections has - it's possible they have a tree that offers fast searching. If you want to stick to the standard Java libraries, you'll want a Set for fast searching. TreeSet keeps the entries in sorted order. If you also need to display them as a tree, you can keep them in both a Set and a tree. If you don't have enough memory to do that, then displaying the whole tree isn't going to be useful to the user anyway, so rethink your goal.

Similar Messages

Best way to store small amount of data to file?

If I need to store, edit, and retrieve small amounts of data for a desktop app (let's say a small address book with name, address, phone, etc), what are my choices with JavaFX? As far as I can tell, there is no built-in database to handle this...
What about the same need for a web-based app?
thanks

You can use with Netbeans Composer a DataSource and manipulate items with the Query Langage.
Link

Best way to store large amounts of data

Greetings!
I have some code that will parse through XML data one character at a time, determine if it's an opening or closing tag, what the tag name is, and what the value between the tags is. All of the results are saved in a 2D string array. Each parent result can have a variable number of child results associated with it and it is possible to have over 2,000 parent results.
Currently, I initialize a new string that I will use to store the values at the beginning of the method.
String[][] initialXMLValues = new String[2000][45]I have no idea how many results will actually be returned when the method is initially called, so I don't know what to do besides make initialXMLValues around the maximum values I expect to have.
As I parse through the XML, I look for a predefined tag that signifies the start of a result. Each tag/value that follows is stored in a single element of an arraylist in the form "tagname,value". When I reach the closing parent tag, I convert the arraylist to a String[], store the size of the array if it is bigger than the previous array (to track the maximum size of the child results), store it in initialXMLValues[i.] (<- peroid to avoid post showing up in italics), then increment i
When I'm all done parsing, I create a new String String[][] XMLValues = new String[i][j], where i is equal to the total number of parent results (from last paragraph) and j is equal to the maximum number of child results. I then use a nested for loop to store all of the values from initialXMLValues into XMLValues. The whole point of this is to minimize the overall size of the returned String Array and minimize the number of null valued fields.
I know this is terribly inefficient, but I don't know a better way to do it. The problem is having to have the size of the array initilized before I really know how many results I'm going to end up storing. Is there a better way to do this?

So I'm starting to rewrite my code. I was shocked at how easy it was to implement the SAX parser, but it works great. Now I'm on to doing away with my nasty string arrays.
Of course, the basic layout of the XML is like this:
<result1>
<element1>value</element1>
<element2>value</element2>
</result1>
<result2>
I thought about storing each element/value in a HashMap for each result. This works great for a single result. But what if I have 1000 results? Do I store 1000 HashMaps in an ArrayList (if that's even possible)? Is there a way to define an array of HashMaps?

What is the best way to store and search 2D data

Hi,
There is a set of data (~10k records ) in 2D dimension.
like this :
Col 1, Col 2, Col3....
What is the best way to store and search those records ?
Thanks in advance
Wilson

Hi,
Either userObjet[][] if you know how much data you have, and the data size is fixed, or use a list of lists. E.g. A Vector of Vectors (some will probably say that you should use an ArrayList instead, and that could be the case, but it sounds like you would want to display the data later on, and a DefaultTableModel (for JTables) uses a Vector as data holder).
Kaj

Best way to store, present en input date/time

Hi!
I hope I can make myself clear. I'm designing an APEX application that has a couple of different date-type fields. That application is going to be translated in two different languages, that has different date/time representations. For example: dd-mon-yyyy hh12:miAM and dd-mm-yyyy hh24:mi. I'm now finding out what's the best way to store those date/time fields and hou I can present them in a report/form and how the user can enter them in a field.
This is what I see:
- I can set an application date format/application timestamp format. This has to be the in the format of the main language, in this case, English.
- I also can make translated versions of the application. QUESTION: can I enter a different date format for the translated application?
Do I have to make my fields of the date type or timestamp type?
I hope someone can answer. If I'm not clear, please tell me!

You can set the application date format using an application item
&DATE_FORMAT_MASK.
and set this item dynamically.
Home>Application Builder>Application ####>Shared Components>Edit Globalization Attributes
Denes Kubicek
http://deneskubicek.blogspot.com/
http://www.opal-consulting.de/training
http://apex.oracle.com/pls/otn/f?p=31517:1
http://www.amazon.de/Oracle-APEX-XE-Praxis/dp/3826655494
-------------------------------------------------------------------

Best way to pass large amounts of data to subroutines?

I'm writing a program with a large amount of data, around 900 variables. What is the best way for me to pass parts of this data to different subroutines? I have a main loop on a PXI RT Controller that is controlling hydraulic cylinders and the loop needs to be 1ms or better. How on earth should I pass 900 variables through a loop and keep it at 1ms? One large cluster?? Several smaller clusters?? Local Variables? Global Variables?? Help me please!!!

My suggestion, similar to Altenbach and Matt above, is to use a Functional Global Variable (FGV) and use a 1D array of 900 values to store the data in the FGV. You can retrieve individual data items from the FGV by passing in the index of the desired variable and the FGV returns the value from the array. Instead of passing in an index you could also use a TypeDef'd Enum with all of your variables as element of the Enum, which will allow you to place the Enum constant on the diagram and make selecting variables, as well as reading the diagram, simpler.
My group is developing a LabVIEW component/example code with this functionality that we plan to publish on DevZone in a month or two.
The attached RTF file shows the core piece of this implementation. This VI off course is non-reentrant. The Init case could be changed to allocate the internal 1D array as part of this VI rather than passing it from another VI.
Message Edited by Christian L on 01-31-2007 12:00 PM
Christian Loew, CLA
Principal Systems Engineer, National Instruments
Please tip your answer providers with kudos.
Any attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system,
or for use in hazardous environments. You assume all risks for use of the Code and use of the Code is subject
to the Sample Code License Terms which can be found at: http://ni.com/samplecodelicense
Attachments:
CVT_Double_MemBlock.rtf ‏309 KB

Best way to store and back up data on Mac (retina)?

Ok so I bought the 13 inch retina macbook pro (This is my very first mac btw, so I am still trying to get used to basic functions though it's getting there..) and I've researched it a bit but I have some issues on figuring out how I best should store my data.
1. Is Time Machine not the best way to back up data? As it will delete the oldest data once the hardrive used is full?
but on the other hand, backing things up manually will take a lot of pain and effort (Choosing the new files that haven't been transferred, accidentally copying a file you actually already put in your back up disk thus taking additional unnecessary space,etc) ...right?
or is there a better way to do this?
2. I want to have all media (music, photos, videos, anything except apps) on an external hard drive but I don't want to have to keep transferring it from iphotos or anything else to my external hard drive...
Is there a way to do this a smarter way? It would be best if I could put everything directly to my harddrive instead of having to import thru iphotos (thus taking up space on my internal SSD first) THEN deleting it from iphotos :/
As of now I am trying do configure this network storage system (called SeaGate GoFlex Home if anyone is interested) but I am wondering if this is really a reliable way to keep my stuff... I plan on putting music, photos and videos on there..along with word documents
Is there a way to configure the mac to automatically download stuff to my external network drive instead of saving it on my SSD?
Thanks in advance for any help /opinions

kj8P wrote:
Is Time Machine not the best way to back up data? As it will delete the oldest data once the hardrive used is full?
Although Time Machine does delete oldest data when full, it doesn't back everything up every time - only the files that have changed since the last backup. Storage is cheap these days so if you get a good sized drive (seems daft to get less than 1Tb and 2 or 3Tb cost not a great deal more), then unless you have a really large SSD on your MBP and fill it with stuff, it will be a long time before Time Machine starts deleting old stuff. Aim for a minimum of double your SSD capacity.
This article gives a very detailed explanation of Time Machine and how it works - bear in mind that even when TM has to delete the oldest backups, it will not delete something that does not have a newer version.
http://icanhelpyourmac.com/tip_archive/understanding_apples_time_machine/index.h tml

Theory - Best way to store this type of data for retrieval?

Hi everyone,
So I'm pretty new to databases and I'm trying to figure out an efficient way to retrieve this kind of data:
an ID that is 36 digits long
col1 = {option1, option2, option3...}
col2 = {option1, option2, option3...}
coln = {option1, option2, option3...}
I need to be able to perform queries on the data based on some concatenation of 3 digit sequences for the ID
for example, I may want to retrieve all the records where the ID begins with '123' or where the ID begins with '123123', or '123123200', etc,
There are going to be close to a billion if not more of these records
the 3 digit sequences will always be a number between 000-255
It is not necessary for me to have a 36 digit long ID, I simply chose that because it seemed like the simplest way to associate a record with its combination of 3 digit sequences.
Like I said, I'm very new to databases. I've been doing a lot of reading on indexing and clustering and nested tables and partitions, but I'm not quite sure which of these I should pursue with this kind of data. Most of the examples that I've read about don't really deal about querying with variable precision.
Would the best way to get this data simply be to use an 'is like' statement on the ID? If so, are there any kinds of indexing I should take a look at that would benefit from knowing that the is like statements would follow the format of <3 digits,3 digits,3 digits>? Also, at the data level, would it be more efficient to use hexadecimal to store the sequences of 3 digits since they conviently fall in the range of 00-FF? I'm just throwing ideas out there, I haven't found much help browsing the web, but maybe I haven't looked in the right place. If anyone has any ideas or places to redirect me, it would be great!
Also, I know sometimes it helps to know the main kind of queries on the data that someone is primarily concerned about. In this case, most queries will be selective counts, for example finding the number of records whose ID's begin with '123006011' and col1='option1'.
Thanks,
Alex
Edited by: user9022475 on Jun 23, 2010 9:37 AM

So I'm starting to rewrite my code. I was shocked at how easy it was to implement the SAX parser, but it works great. Now I'm on to doing away with my nasty string arrays.
Of course, the basic layout of the XML is like this:
<result1>
<element1>value</element1>
<element2>value</element2>
</result1>
<result2>
I thought about storing each element/value in a HashMap for each result. This works great for a single result. But what if I have 1000 results? Do I store 1000 HashMaps in an ArrayList (if that's even possible)? Is there a way to define an array of HashMaps?

Best way of handling large amounts of data movement

Hi
I like to know what is the best way to handle data in the following scenario
1. We have to create Medical and Rx claims Tables for 36 months of data about 150 million records each - First month (month 1, 2, 3, 4, .......34, 35, 36)
2. We have to add the DELTA of month two to the 36 month baseline. But the application requirement is ONLY 36 months, even though the current size is 37 months.
3 Similarly in the 3rd month we will have 38 months, 4th month will have 39 months.
4. At the end of 4th month - how can I delete the First three months of data from Claim files without affecting the performance which is a 24X7 Online system.
5. Is there a way to create Partitions of 3 months each and that can be deleted - Delete Partition number 1, If this is possible, then what kind of maintenance activity needs to be done after deleting partition.
6. Is there any better way of doing the above scenario. What other options do I have.
7 My goal is to eliminate the initial months data from system as the requirement is ONLY 36 months data.
Thanks in advance for your suggestion
sekhar

Hi,
You should use table partitioning to keep your data on monthly partitions. Serach on table partitioning for detailed examples.
Regards

Best way to store a LOT of data?

Hi guys,
I have a program which contains two arrays of several objects(ie Objects containing other Objects) which I need to store. The arrays can be anywhere from 1000-7000 objects.
I have used xstream to write this data to disk and I get a file size of about 300mb, which is about 1:1 ratio compared to having the object in memory at runtime.
Does anyone know of any better algorithms to reduce to file size or is this impossible?
Thanks!

Alternatively, you could just use a GZip output stream to compress it on the way out. It would slow you down a bit, though.
http://java.sun.com/j2se/1.5.0/docs/api/java/util/zip/GZIPOutputStream.html
Example of XStream w/ GZipOutputStream:
http://permalink.gmane.org/gmane.comp.java.xstream.user/692
Message was edited by:
kevjava

What is the best way to migrate large amounts of data from a g3 to an intel mac?

I want to help my mom transfer her photos and other info from an older blueberry G3 iMac to a new intel one. There appears to be no prmigration provision on the older mac. Also the firewire caconnestions are different. Somebody must have done this before.

Hello
the cable above can be use to enable Target Disk mode for data transfert
http://support.apple.com/kb/ht1661 for more info
to enable Target Disk mode just after startup sound Hold on "T" key on key board until see at screen firewire symbol aka screen saver , then plug fire wire cable betwen 2 mac
HTH
Pierre

Best way to store data from a plot on hard drive

I have a DAQ set-up that will be on 24/7 for several days, and the whole time it's streaming data to an XY-Graph with a limited buffer. My question is, what's the best way to store my plot data in such a way that I can empty out my plot every few hours but if I want to pull up data from a few hours ago I would just have an option on my initial VI to view any old saved plot data.
Basically, I'm trying to not overload my RAM with all my plot data so I'd like to save it to the hard drive while my VI is running, and only display, for example the last 8 hours worth of data... I've been looking at TDMS, but I'm not sure if that's the right solution.
much thanks!

Hi,
You could save your data using TDMS as well as ASCII to simply load it in another application later.
Attached VI shows you how to save your data to a File after a certain amount of iterations, you can combine this then with your code and a timestamp.
Christian
Attachments:
Save to new file every N samples.vi ‏20 KB

Best way to store all this data!!

Hi i have run into a problem and cant think at the mo. I need to know the best way to store this data:
Meet(List of events in meet, Runners in meet, Relay team in meet, Which runner/ relay team is registered for which event, results of each event updated once meet is run, event being run(or has finished) or not started yet so runners can still register for it);
Runner(RunnerID, Name, D.O.B, national team affiliation, Gender, Events in?, Seedtime for each event?, actual time for event?)
RelayTeam(RelayID, Team name, Runner names, seedtime for events, events in, Acutal time)
Event(ID, Name, Meet in, Runners in which lane)
I just want to know how i can store these to make it as easy as possible to update etc.
Anyhelp apprec.
Thanks
J

Crossposted: http://forums.java.sun.com/thread.jsp?thread=509544&forum=31&message=2419334

What's the best way to store my info externally

I have recently bought my first Macbook Pro 13" with 2.4 Ghz. I am currently using it for my own business and do tend to get a lot of files together. I went to look at "About this Mac" and have already got 369 Gb used up in storage... I have no idea how I have done that as I have hardly downloaded any apps on this computer besides the ones that were on here. I did download Vware Fusion 4 as I have a reservation system which I used to run on my pc and need to have this on here too so perhaps that software takes a lot of space.
Could anyone advise on which is the best way to store my info externally, will any external harddrive do, or do you need a special one for Apple or Macbook pro. I am just asking as I have no idea and prefer to buy the right one straight away.
Any help would be much appreciated !
Thanks, Sara***

Sara,
The most reliable method is to use an external hard drive. Some are better than others, but most will work.
For the least amount of setup pain, I prefer to deal with the Mac specialists at OWC, http://www.macsales.com as they stand behind their products with great warranty and support. I have one of their Mercury Elite Pro 2 TB drives that has multiple interface capability so you can get a fast interface for data transfer.
Take a look at what they offer and see what fits your needs. If you have more questions about doing thin, just ask on here.
Ralph

How can I return a big amount of data from a stored procedure?

How can I return a big amount of data from a stored procedure in a efficient way ?
For example not using a cursor for going through all the rows and then assign the values to variables.
thanks in advance!

Let's see if I'm able to explain myself..
I have a SQL query with..about 190.000 (in the best fo the the options)
I have something like this in my stored procedure..
FOR REC IN trn_adj_no
LOOP
REC_PIPE.INSTANCE_ID:=REC.INSTANCE_ID;
REC_PIPE.PROCESS_ID:=REC.PROCESS_ID;
REC_PIPE.ENTITY_TYPE:='TRANSACTION';
REC_PIPE.CRES_FILENAME:=REC.CRES_FILENAME;
REC_PIPE.CHUNK_REVISION_SK:=P_CHUNK_REVISION_SK;
REC_PIPE.CHUNK_ID:=trim(p_chunk_id);
REC_PIPE.FCL_SK:=REC.FCL_SK;
REC_PIPE.FCL_TRADE_SK:=REC.FCL_TRADE_SK;
REC_PIPE.FCL_VALUATION_SK:=REC.FCL_VALUATION_SK;
REC_PIPE.FCL_BUSINESS_GROUP:=REC.FCL_BUSINESS_GROUP;
REC_PIPE.ABS_TRN_CD:=REC.ABS_TRN_CD;
REC_PIPE.ACC_INTEREST_IMP_LOAN_CCY_IFRS:=REC.ACC_INTEREST_IMP_LOAN_CCY_IFRS;
REC_PIPE.ACC_INTEREST_IMP_LOAN_IFRS:=REC.ACC_INTEREST_IMP_LOAN_IFRS;
REC_PIPE.ACCRUED_INT_AMT:=REC.ACCRUED_INT_AMT;
REC_PIPE.ACCRUED_INT_CCY_CD:=REC.ACCRUED_INT_CCY_CD;
REC_PIPE.AMORT_ID:=REC.AMORT_ID;
REC_PIPE.AMORT_IND:=REC.AMORT_IND;
REC_PIPE.ATI:=REC.ATI;
REC_PIPE.ATI_2:=REC.ATI_2;
REC_PIPE.ATI_2_AMT:=REC.ATI_2_AMT;
REC_PIPE.ATI_2_CCY_CD:=REC.ATI_2_CCY_CD;
REC_PIPE.ATI_AMT:=REC.ATI_AMT;
REC_PIPE.ATI_CCY_CD:=REC.ATI_CCY_CD;
REC_PIPE.AVG_MTH_DUE_AMT:=REC.AVG_MTH_DUE_AMT;
REC_PIPE.AVG_MTH_DUE_CCY_CD:=REC.AVG_MTH_DUE_CCY_CD;
REC_PIPE.AVG_YTD_DUE_AMT:=REC.AVG_YTD_DUE_AMT;
REC_PIPE.AVG_YTD_DUE_CCY_CD:=REC.AVG_YTD_DUE_CCY_CD;
REC_PIPE.BAL_SHEET_EXP_AMT:=REC.BAL_SHEET_EXP_AMT;
REC_PIPE.BAL_SHEET_EXP_AMT_IFRS:=REC.BAL_SHEET_EXP_AMT_IFRS;
REC_PIPE.BAL_SHEET_EXP_CCY_CD:=REC.BAL_SHEET_EXP_CCY_CD;
REC_PIPE.BAL_SHEET_EXP_CCY_CD_IFRS:=REC.BAL_SHEET_EXP_CCY_CD_IFRS;
REC_PIPE.BAL_SHEET_EXP_EUR_AMT:=REC.BAL_SHEET_EXP_EUR_AMT;
REC_PIPE.BAL_SHEET_EXP_EUR_AMT_IFRS:=REC.BAL_SHEET_EXP_EUR_AMT_IFRS;
REC_PIPE.BEN_CCDB_ID:=REC.BEN_CCDB_ID;
REC_PIPE.BEN_CD:=REC.BEN_CD;
REC_PIPE.BEN_SRC_CD:=REC.BEN_SRC_CD;
REC_PIPE.BOOK_CD:=REC.BOOK_CD;
REC_PIPE.BOOK_TYPE_CD:=REC.BOOK_TYPE_CD;
REC_PIPE.BOOK_VAL_AMT:=REC.BOOK_VAL_AMT;
REC_PIPE.BOOK_VAL_AMT_IFRS:=REC.BOOK_VAL_AMT_IFRS;
REC_PIPE.BOOK_VAL_CCY_CD:=REC.BOOK_VAL_CCY_CD;
REC_PIPE.BOOK_VAL_CCY_CD_IFRS:=REC.BOOK_VAL_CCY_CD_IFRS;
REC_PIPE.BOOK_VAL_US_GAAP_AMT:=REC.BOOK_VAL_US_GAAP_AMT;
REC_PIPE.BRANCH_ID:=REC.BRANCH_ID;
REC_PIPE.BRANCH_LOC_CD:=REC.BRANCH_LOC_CD;
REC_PIPE.BS_COMPEN_CD:=REC.BS_COMPEN_CD;
REC_PIPE.BUS_AREA_UBR_ID:=REC.BUS_AREA_UBR_ID;
REC_PIPE.CA_CD:=REC.CA_CD;
REC_PIPE.CAD_RISK_WEIGHT_PCT:=REC.CAD_RISK_WEIGHT_PCT;
REC_PIPE.CASH_SETTLE_IND:=REC.CASH_SETTLE_IND;
REC_PIPE.CLS_FLG:=REC.CLS_FLG;
REC_PIPE.COB_DT:=REC.COB_DT;
REC_PIPE.COL_AGMENT_SRC_CD:=REC.COL_AGMENT_SRC_CD;
REC_PIPE.CONSOLIDATION_PCT:=REC.CONSOLIDATION_PCT;
REC_PIPE.CONTRACT_AMT:=REC.CONTRACT_AMT;
REC_PIPE.CONTRACT_COUNT:=REC.CONTRACT_COUNT;
REC_PIPE.COST_UNSEC_WORKOUT_AMT:=REC.COST_UNSEC_WORKOUT_AMT;
REC_PIPE.CPTY_CCDB_ID:=REC.CPTY_CCDB_ID;
REC_PIPE.CPTY_CD:=REC.CPTY_CD;
REC_PIPE.CPTY_LONG_NAME:=REC.CPTY_LONG_NAME;
REC_PIPE.CPTY_SRC_PROXY_UBR_ID:=REC.CPTY_SRC_PROXY_UBR_ID;
REC_PIPE.CPTY_TYPE_CD:=REC.CPTY_TYPE_CD;
REC_PIPE.CPTY_UBR_ID:=REC.CPTY_UBR_ID;
REC_PIPE.CREDIT_LINE_NET_IND:=REC.CREDIT_LINE_NET_IND;
REC_PIPE.CRES_SYS_ID:=REC.CRES_SYS_ID;
REC_PIPE.CTRY_RISK_PROVISION_BAL_AMT:=REC.CTRY_RISK_PROVISION_BAL_AMT;
REC_PIPE.CUR_NOTIONAL_AMT:=REC.CUR_NOTIONAL_AMT;
REC_PIPE.CUR_NOTIONAL_CCY_CD:=REC.CUR_NOTIONAL_CCY_CD;
REC_PIPE.CUR_NOTIONAL_CCY_CD_IFRS:=REC.CUR_NOTIONAL_CCY_CD_IFRS;
REC_PIPE.CUR_NOTIONAL_AMT_IFRS:=REC.CUR_NOTIONAL_AMT_IFRS;
REC_PIPE.DB_ENTITY_TRANSFER_ASSETS_CD:=REC.DB_ENTITY_TRANSFER_ASSETS_CD;
REC_PIPE.DEAL_TYPE_CD:=REC.DEAL_TYPE_CD;
REC_PIPE.DECOMPOSITION_IDENTIFIER:=REC.DECOMPOSITION_IDENTIFIER;
REC_PIPE.DEF_LOAN_FEE_IFRS:=REC.DEF_LOAN_FEE_IFRS;
REC_PIPE.DEF_LOAN_FEE_USGAAP:=REC.DEF_LOAN_FEE_USGAAP;
REC_PIPE.DELIVERY_DT:=REC.DELIVERY_DT;
REC_PIPE.DERIV_NOT_DT:=REC.DERIV_NOT_DT;
REC_PIPE.DERIV_NOT_IND:=REC.DERIV_NOT_IND;
REC_PIPE.DESK:=REC.DESK;
REC_PIPE.DIVISION_UBR_ID:=REC.DIVISION_UBR_ID;
REC_PIPE.ENTITY_CCDB_ID:=REC.ENTITY_CCDB_ID;
REC_PIPE.FAC_CD:=REC.FAC_CD;
REC_PIPE.FAC_LIMIT_CD:=REC.FAC_LIMIT_CD;
REC_PIPE.FAC_LIMIT_SRC_CD:=REC.FAC_LIMIT_SRC_CD;
REC_PIPE.FAC_SRC_CD:=REC.FAC_SRC_CD;
REC_PIPE.FAIR_VAL_CD_IFRS:=REC.FAIR_VAL_CD_IFRS;
REC_PIPE.FED_CLASS_CD:=REC.FED_CLASS_CD;
REC_PIPE.FIRST_RISK_PROVISION_DT:=REC.FIRST_RISK_PROVISION_DT;
REC_PIPE.FV_IMP_LOSS_CRED_CCY_IFRS:=REC.FV_IMP_LOSS_CRED_CCY_IFRS;
REC_PIPE.FV_IMP_LOSS_CRED_IFRS:=REC.FV_IMP_LOSS_CRED_IFRS;
REC_PIPE.FV_IMP_LOSS_CRED_YTD_CCY_IFRS:=REC.FV_IMP_LOSS_CRED_YTD_CCY_IFRS;
REC_PIPE.FV_IMP_LOSS_CRED_YTD_IFRS:=REC.FV_IMP_LOSS_CRED_YTD_IFRS;
REC_PIPE.GEN_RISK_PROVISION_BAL_AMT:=REC.GEN_RISK_PROVISION_BAL_AMT;
REC_PIPE.GL_PROFIT_CENTRE:=REC.GL_PROFIT_CENTRE;
REC_PIPE.GLOBAL_GL_CD:=REC.GLOBAL_GL_CD;
REC_PIPE.IFRS_POSITION:=REC.IFRS_POSITION;
REC_PIPE.IFRS_POSITION_AGGR:=REC.IFRS_POSITION_AGGR;
REC_PIPE.IMP_DT:=REC.IMP_DT;
REC_PIPE.IMP_METHOD_CD:=REC.IMP_METHOD_CD;
REC_PIPE.INT_COMPEN_CD:=REC.INT_COMPEN_CD;
REC_PIPE.INTER_IND:=REC.INTER_IND;
REC_PIPE.INTERCO_IND:=REC.INTERCO_IND;
REC_PIPE.INTERCO_IND_IFRS:=REC.INTERCO_IND_IFRS;
REC_PIPE.LOAN_PUR_FAIR_VAL_ADJ_AMT:=REC.LOAN_PUR_FAIR_VAL_ADJ_AMT;
REC_PIPE.LOCAL_GL_CD:=REC.LOCAL_GL_CD;
REC_PIPE.LOWEST_LEVEL_UBR_ID:=REC.LOWEST_LEVEL_UBR_ID;
REC_PIPE.LTD_FEES_TO_PRINCIPAL_AMT:=REC.LTD_FEES_TO_PRINCIPAL_AMT;
REC_PIPE.MA_CD:=REC.MA_CD;
REC_PIPE.MA_SPL_NOTE:=REC.MA_SPL_NOTE;
REC_PIPE.MA_SRC_CD:=REC.MA_SRC_CD;
REC_PIPE.MA_TYPE_CD:=REC.MA_TYPE_CD;
REC_PIPE.MAN_LINK_ID:=REC.MAN_LINK_ID;
REC_PIPE.MASTER_MA_CD:=REC.MASTER_MA_CD;
REC_PIPE.MATURITY_DT:=REC.MATURITY_DT;
REC_PIPE.MAX_OUT_AMT:=REC.MAX_OUT_AMT;
REC_PIPE.MAX_OUT_CCY_CD:=REC.MAX_OUT_CCY_CD;
REC_PIPE.MTM_AMT:=REC.MTM_AMT;
REC_PIPE.MTM_AMT_IFRS:=REC.MTM_AMT_IFRS;
REC_PIPE.MTM_CCY_CD:=REC.MTM_CCY_CD;
REC_PIPE.MTM_CCY_CD_IFRS:=REC.MTM_CCY_CD_IFRS;
REC_PIPE.NEW_RISK_PROVISION_AMT:=REC.NEW_RISK_PROVISION_AMT;
REC_PIPE.NON_PERF_IND:=REC.NON_PERF_IND;
REC_PIPE.NON_PERF_RCV_INT_AMT:=REC.NON_PERF_RCV_INT_AMT;
REC_PIPE.OPT_TYPE_CD:=REC.OPT_TYPE_CD;
REC_PIPE.ORIG_NOTIONAL_AMT:=REC.ORIG_NOTIONAL_AMT;
REC_PIPE.ORIG_NOTIONAL_CCY_CD:=REC.ORIG_NOTIONAL_CCY_CD;
REC_PIPE.ORIG_TRN_CD:=REC.ORIG_TRN_CD;
REC_PIPE.ORIG_TRN_SRC_CD:=REC.ORIG_TRN_SRC_CD;
REC_PIPE.OTHER_CUR_NOTIONAL_AMT:=REC.OTHER_CUR_NOTIONAL_AMT;
REC_PIPE.OTHER_CUR_NOTIONAL_CCY_CD:=REC.OTHER_CUR_NOTIONAL_CCY_CD;
REC_PIPE.OTHER_ORIG_NOTIONAL_AMT:=REC.OTHER_ORIG_NOTIONAL_AMT;
REC_PIPE.OTHER_ORIG_NOTIONAL_CCY_CD:=REC.OTHER_ORIG_NOTIONAL_CCY_CD;
REC_PIPE.OVERDUE_AMT:=REC.OVERDUE_AMT;
REC_PIPE.OVERDUE_CCY_CD:=REC.OVERDUE_CCY_CD;
REC_PIPE.OVERDUE_DAY_COUNT:=REC.OVERDUE_DAY_COUNT;
REC_PIPE.PAY_CONTRACT_AMT:=REC.PAY_CONTRACT_AMT;
REC_PIPE.PAY_CONTRACT_CCY_CD:=REC.PAY_CONTRACT_CCY_CD;
REC_PIPE.PAY_FWD_AMT:=REC.PAY_FWD_AMT;
REC_PIPE.PAY_FWD_CCY_CD:=REC.PAY_FWD_CCY_CD;
REC_PIPE.PAY_INT_INTERVAL:=REC.PAY_INT_INTERVAL;
REC_PIPE.PAY_INT_RATE:=REC.PAY_INT_RATE;
REC_PIPE.PAY_INT_RATE_TYPE_CD:=REC.PAY_INT_RATE_TYPE_CD;
REC_PIPE.PAY_NEXT_FIX_CPN_DT:=REC.PAY_NEXT_FIX_CPN_DT;
REC_PIPE.PAY_UL_SEC_TYPE_CD:=REC.PAY_UL_SEC_TYPE_CD;
REC_PIPE.PAY_UL_ISS_CCDB_ID:=REC.PAY_UL_ISS_CCDB_ID;
REC_PIPE.PAY_UL_MTM_AMT:=REC.PAY_UL_MTM_AMT;
REC_PIPE.PAY_UL_MTM_CCY_CD:=REC.PAY_UL_MTM_CCY_CD;
REC_PIPE.PAY_UL_SEC_CCY_CD:=REC.PAY_UL_SEC_CCY_CD;
REC_PIPE.PAY_UL_SEC_CD:=REC.PAY_UL_SEC_CD;
REC_PIPE.PCP_TRANSACTION_SK:=REC.PCP_TRANSACTION_SK;
REC_PIPE.PROD_AREA_UBR_ID:=REC.PROD_AREA_UBR_ID;
REC_PIPE.QUOTA_PART_AMT:=REC.QUOTA_PART_AMT;
REC_PIPE.RCV_CONTRACT_AMT:=REC.RCV_CONTRACT_AMT;
REC_PIPE.RCV_CONTRACT_CCY_CD:=REC.RCV_CONTRACT_CCY_CD;
REC_PIPE.RCV_FWD_AMT:=REC.RCV_FWD_AMT;
REC_PIPE.RCV_FWD_CCY_CD:=REC.RCV_FWD_CCY_CD;
REC_PIPE.RCV_INT_RATE:=REC.RCV_INT_RATE;
REC_PIPE.RCV_INT_RATE_TYPE_CD:=REC.RCV_INT_RATE_TYPE_CD;
REC_PIPE.RCV_INT_INTERVAL:=REC.RCV_INT_INTERVAL;
REC_PIPE.RCV_NEXT_FIX_CPN_DT:=REC.RCV_NEXT_FIX_CPN_DT;
REC_PIPE.RCV_UL_ISS_CCDB_ID:=REC.RCV_UL_ISS_CCDB_ID;
REC_PIPE.RCV_UL_MTM_AMT:=REC.RCV_UL_MTM_AMT;
REC_PIPE.RCV_UL_MTM_CCY_CD:=REC.RCV_UL_MTM_CCY_CD;
REC_PIPE.RCV_UL_SEC_CCY_CD:=REC.RCV_UL_SEC_CCY_CD;
REC_PIPE.RCV_UL_SEC_CD:=REC.RCV_UL_SEC_CD;
REC_PIPE.RCV_UL_SEC_TYPE_CD:=REC.RCV_UL_SEC_TYPE_CD;
REC_PIPE.REC_SEC_AMT:=REC.REC_SEC_AMT;
REC_PIPE.REC_SEC_CCY_CD:=REC.REC_SEC_CCY_CD;
REC_PIPE.REC_UNSEC_AMT:=REC.REC_UNSEC_AMT;
REC_PIPE.REC_UNSEC_CCY_CD:=REC.REC_UNSEC_CCY_CD;
REC_PIPE.RECON_CD:=REC.RECON_CD;
REC_PIPE.RECON_SRC_CD:=REC.RECON_SRC_CD;
REC_PIPE.RECOV_AMT:=REC.RECOV_AMT;
REC_PIPE.RECOVERY_FLAG:=REC.RECOVERY_FLAG;
REC_PIPE.REGULATORY_NET_IND:=REC.REGULATORY_NET_IND;
REC_PIPE.REL_RISK_PROVISION_AMT:=REC.REL_RISK_PROVISION_AMT;
REC_PIPE.RESPONSIBLE_BRANCH_CCDB_ID:=REC.RESPONSIBLE_BRANCH_CCDB_ID;
REC_PIPE.RESPONSIBLE_BRANCH_ID:=REC.RESPONSIBLE_BRANCH_ID;
REC_PIPE.RESPONSIBLE_BRANCH_LOC_CD:=REC.RESPONSIBLE_BRANCH_LOC_CD;
REC_PIPE.RESTRUCT_IND:=REC.RESTRUCT_IND;
REC_PIPE.RISK_END_DT:=REC.RISK_END_DT;
REC_PIPE.RISK_ENGINES_METHOD_USED:=REC.RISK_ENGINES_METHOD_USED;
REC_PIPE.RISK_MITIGATING_PCT:=REC.RISK_MITIGATING_PCT;
REC_PIPE.RISK_PROVISION_BAL_AMT:=REC.RISK_PROVISION_BAL_AMT;
REC_PIPE.RISK_PROVISION_CCY_CD:=REC.RISK_PROVISION_CCY_CD;
REC_PIPE.RISK_WRITE_OFF_AMT:=REC.RISK_WRITE_OFF_AMT;
REC_PIPE.RISK_WRITE_OFF_LIFE_DT_AMT:=REC.RISK_WRITE_OFF_LIFE_DT_AMT;
REC_PIPE.RT_BUS_AREA_UBR_ID:=REC.RT_BUS_AREA_UBR_ID;
REC_PIPE.RT_CB_CCDB_ID:=REC.RT_CB_CCDB_ID;
REC_PIPE.RT_COV_CD:=REC.RT_COV_CD;
REC_PIPE.RT_COV_SRC_CD:=REC.RT_COV_SRC_CD;
REC_PIPE.RT_COV_TYPE_CD:=REC.RT_COV_TYPE_CD;
REC_PIPE.RT_COV_TYPE_CD_IFRS:=REC.RT_COV_TYPE_CD_IFRS;
REC_PIPE.RT_TYPE_CD:=REC.RT_TYPE_CD;
REC_PIPE.RT_TYPE_CD_IFRS:=REC.RT_TYPE_CD_IFRS;
REC_PIPE.SENIORITY:=REC.SENIORITY;
REC_PIPE.SETTLE_STATUS_ID:=REC.SETTLE_STATUS_ID;
REC_PIPE.SETTLEMENT_CD:=REC.SETTLEMENT_CD;
REC_PIPE.SETTLEMENT_DT:=REC.SETTLEMENT_DT;
REC_PIPE.SOX_REF:=REC.SOX_REF;
REC_PIPE.SPE_IND:=REC.SPE_IND;
REC_PIPE.SPL_TREAT_IND_IFRS:=REC.SPL_TREAT_IND_IFRS;
REC_PIPE.SRC_PROD_TYPE_CD:=REC.SRC_PROD_TYPE_CD;
REC_PIPE.SRC_PROD_TYPE_CD_IFRS:=REC.SRC_PROD_TYPE_CD_IFRS;
REC_PIPE.SRC_PROXY_UBR_CD:=REC.SRC_PROXY_UBR_CD;
REC_PIPE.START_DT:=REC.START_DT;
REC_PIPE.STRATEGIC_LEND_IND:=REC.STRATEGIC_LEND_IND;
REC_PIPE.STRIKE_FWD_FUT_PRICE_AMT:=REC.STRIKE_FWD_FUT_PRICE_AMT;
REC_PIPE.STRIKE_FWD_FUT_PRICE_CCY_CD:=REC.STRIKE_FWD_FUT_PRICE_CCY_CD;
REC_PIPE.TERMINATION_LOAN_DT:=REC.TERMINATION_LOAN_DT;
REC_PIPE.TRAD_ASSET_CD_IFRS:=REC.TRAD_ASSET_CD_IFRS;
REC_PIPE.TRADE_DT:=REC.TRADE_DT;
REC_PIPE.TRADE_ENTITY_CCDB_ID:=REC.TRADE_ENTITY_CCDB_ID;
REC_PIPE.TRADE_ENTITY_LOC_CD:=REC.TRADE_ENTITY_LOC_CD;
REC_PIPE.TRADE_RELATED_IND:=REC.TRADE_RELATED_IND;
REC_PIPE.TRADE_STATUS:=REC.TRADE_STATUS;
REC_PIPE.TRADING_ENTITY_LOC_CD:=REC.TRADING_ENTITY_LOC_CD;
REC_PIPE.TRAN_MATCH_CD:=REC.TRAN_MATCH_CD;
REC_PIPE.TRN_CD:=REC.TRN_CD;
REC_PIPE.TRN_LINK_CD:=REC.TRN_LINK_CD;
REC_PIPE.TRN_SRC_CD:=REC.TRN_SRC_CD;
REC_PIPE.TRN_TYPE_CD:=REC.TRN_TYPE_CD;
REC_PIPE.TRN_VERSION:=REC.TRN_VERSION;
REC_PIPE.UL_DELIVERY_DT:=REC.UL_DELIVERY_DT;
REC_PIPE.UL_MATURITY_DT:=REC.UL_MATURITY_DT;
REC_PIPE.UNDLY_ISS_NAME:=REC.UNDLY_ISS_NAME;
REC_PIPE.UNEARNED_INCOME_CCY_CD:=REC.UNEARNED_INCOME_CCY_CD;
REC_PIPE.UNEARNED_INCOME_DIS_LOAN_AMT:=REC.UNEARNED_INCOME_DIS_LOAN_AMT;
REC_PIPE.US_GAAP_POSITION_AGGR:=REC.US_GAAP_POSITION_AGGR;
REC_PIPE.VALUATION_DT:=REC.VALUATION_DT;
REC_PIPE.XCHG_CTRY_CD:=REC.XCHG_CTRY_CD;
REC_PIPE.YEAR01_NOTIONAL_AMT:=REC.YEAR01_NOTIONAL_AMT;
REC_PIPE.YEAR02_NOTIONAL_AMT:=REC.YEAR02_NOTIONAL_AMT;
REC_PIPE.YEAR03_NOTIONAL_AMT:=REC.YEAR03_NOTIONAL_AMT;
REC_PIPE.YEAR04_NOTIONAL_AMT:=REC.YEAR04_NOTIONAL_AMT;
REC_PIPE.YEAR05_NOTIONAL_AMT:=REC.YEAR05_NOTIONAL_AMT;
REC_PIPE.YEAR06_NOTIONAL_AMT:=REC.YEAR06_NOTIONAL_AMT;
REC_PIPE.YEAR07_NOTIONAL_AMT:=REC.YEAR07_NOTIONAL_AMT;
REC_PIPE.YEAR08_NOTIONAL_AMT:=REC.YEAR08_NOTIONAL_AMT;
REC_PIPE.YEAR09_NOTIONAL_AMT:=REC.YEAR09_NOTIONAL_AMT;
REC_PIPE.YEAR10_NOTIONAL_AMT:=REC.YEAR10_NOTIONAL_AMT;
REC_PIPE.YTD_PL_TRADE_AMT:=REC.YTD_PL_TRADE_AMT;
REC_PIPE.FCL_VALIDATED_IND:=REC.FCL_VALIDATED_IND;
REC_PIPE.FCL_EXCLUDED_IND:=REC.FCL_EXCLUDED_IND;
REC_PIPE.FCL_SOURCE_SYSTEM:=REC.FCL_SOURCE_SYSTEM;
REC_PIPE.FCL_CREATE_TIMESTAMP:=REC.FCL_CREATE_TIMESTAMP;
REC_PIPE.FCL_UPDATE_TIMESTAMP:=REC.FCL_UPDATE_TIMESTAMP;
REC_PIPE.FCL_TRADE_LOAD_DATE:=REC.FCL_TRADE_LOAD_DATE;
REC_PIPE.FCL_VALUATION_LOAD_DATE:=REC.FCL_VALUATION_LOAD_DATE;
REC_PIPE.FCL_MATRIX_TRADE_TYPE:=REC.FCL_MATRIX_TRADE_TYPE;
REC_PIPE.PCP_GCDS_REVISION:=REC.PCP_GCDS_REVISION;
REC_PIPE.FCL_UTP_BOOK_CD:=REC.FCL_UTP_BOOK_CD;
REC_PIPE.FCL_MIS_RISK_BOOK_CD:=REC.FCL_MIS_RISK_BOOK_CD;
REC_PIPE.ALD_STATUS:=REC.ALD_STATUS;
REC_PIPE.FCAT_OPERATION:=REC.FCAT_OPERATION;
REC_PIPE.INTERNAL_INTRA_IND_IFRS:=REC.INTERNAL_INTRA_IND_IFRS;
REC_PIPE.FCL_USAGE_IND:=REC.FCL_USAGE_IND;
REC_PIPE.QUICK:=REC.QUICK;
REC_PIPE.SEDOL:=REC.SEDOL;
REC_PIPE.CUSIP:=REC.CUSIP;
REC_PIPE.ISIN:=REC.ISIN;
REC_PIPE.QUANTITY:=REC.QUANTITY;
REC_PIPE.RIC:=REC.RIC;
REC_PIPE.DESCRIPTION:=REC.DESCRIPTION;
REC_PIPE.RESET_DATE:=REC.RESET_DATE;
REC_PIPE.PRICE:=REC.PRICE;
REC_PIPE.EXCHANGERATE:=REC.EXCHANGERATE;
REC_PIPE.PARA_PROD_TYPE_ID:=REC.PARA_PROD_TYPE_ID;
REC_PIPE.EFF_INT_RATE:=REC.EFF_INT_RATE;
REC_PIPE.ORIG_FEE_UNREALISED_AMT:=REC.ORIG_FEE_UNREALISED_AMT;
REC_PIPE.ASSET_TYPE:=REC.ASSET_TYPE;
REC_PIPE.IMP_IND_IFRS:=REC.IMP_IND_IFRS;
REC_PIPE.NOT_AMT_REDEMPTION_TO_1YR:=REC.NOT_AMT_REDEMPTION_TO_1YR;
REC_PIPE.NOT_AMT_REDEMPTION_TO_5YR:=REC.NOT_AMT_REDEMPTION_TO_5YR;
REC_PIPE.NOT_AMT_REDEMPTION_OVER_5YR:=REC.NOT_AMT_REDEMPTION_OVER_5YR;
REC_PIPE.CASH_LTD:=REC.CASH_LTD;
REC_PIPE.CASH_LTD_CCY:=REC.CASH_LTD_CCY;
REC_PIPE.FCL_FACILITY_SK:=REC.FCL_FACILITY_SK;
REC_PIPE.DILUTION_RISK_CRITERIA:=REC.DILUTION_RISK_CRITERIA;
REC_PIPE.FCL_RMS_RUNID:=REC.FCL_RMS_RUNID;
REC_PIPE.BSTYPE:=REC.BSTYPE;
REC_PIPE.YTD_ACCR_DIV:=REC.YTD_ACCR_DIV;
REC_PIPE.YTD_DIV:=REC.YTD_DIV;
REC_PIPE.ACC_ADJ_YTD:=REC.ACC_ADJ_YTD;
REC_PIPE.FV_RLZD_PL:=REC.FV_RLZD_PL;
REC_PIPE.ITD_PL:=REC.ITD_PL;
REC_PIPE.YTD_RLZD_PL:=REC.YTD_RLZD_PL;
REC_PIPE.YTD_UNRLZD_PL:=REC.YTD_UNRLZD_PL;
REC_PIPE.TRN_BAS_LGD:=REC.TRN_BAS_LGD;
REC_PIPE.TRAD_YTD_RLZD_PL:=REC.TRAD_YTD_RLZD_PL;
REC_PIPE.TRAD_YTD_UNRLZD_PL:=REC.TRAD_YTD_UNRLZD_PL;
REC_PIPE.UNADJUSTED_PV:=REC.UNADJUSTED_PV;
REC_PIPE.UNADJUSTED_REALISED_PL:=REC.UNADJUSTED_REALISED_PL;
REC_PIPE.UNADJUSTED_UNREALISED_PL:=REC.UNADJUSTED_UNREALISED_PL;
REC_PIPE.GRC_PROD_TYPE_ID:=REC.GRC_PROD_TYPE_ID;
REC_PIPE.GRC_PROD_TYPE_ID_IFRS:=REC.GRC_PROD_TYPE_ID_IFRS;
REC_PIPE.CUR_FEE:=REC.CUR_FEE;
REC_PIPE.SEC_IND:=REC.SEC_IND;
REC_PIPE.INVEST_ASSETS_PORT:=REC.INVEST_ASSETS_PORT;
REC_PIPE.RISK_PROVISION_START_BAL_AMT:=REC.RISK_PROVISION_START_BAL_AMT;
REC_PIPE.GEN_RISK_PRV_START_BAL_AMT:=REC.GEN_RISK_PRV_START_BAL_AMT;
REC_PIPE.GEN_RISK_PROVISION_NEW:=REC.GEN_RISK_PROVISION_NEW;
REC_PIPE.GEN_RISK_PROVISION_REL:=REC.GEN_RISK_PROVISION_REL;
REC_PIPE.ACQUIRED_IND:=REC.ACQUIRED_IND;
REC_PIPE.CRED_NET_MNA:=REC.CRED_NET_MNA;
REC_PIPE.SEC_IFRS_VUE_ADJ:=REC.SEC_IFRS_VUE_ADJ;
REC_PIPE.YEAR00_NOTIONAL_AMT:=REC.YEAR00_NOTIONAL_AMT;
REC_PIPE.MAX_OVERDUE_DAYS:=REC.MAX_OVERDUE_DAYS;
REC_PIPE.MIS_CD:=REC.MIS_CD;
REC_PIPE.MULTINAME_POOL_SK:=REC.MULTINAME_POOL_SK;
REC_PIPE.MULTINAME_CHUNK_REVISION_SK:=REC.MULTINAME_CHUNK_REVISION_SK;
REC_PIPE.MTRX_CALC_CNTRL_EPE:=REC.MTRX_CALC_CNTRL_EPE;
REC_PIPE.MTRX_CALC_CNTRL_PFE:=REC.MTRX_CALC_CNTRL_PFE;
REC_PIPE.FCL_TE_VALIDATED_IND:=REC.FCL_TE_VALIDATED_IND;
REC_PIPE.PCP_TE_DYNAMIC_KEY:=REC.PCP_TE_DYNAMIC_KEY;
REC_PIPE.AVG_COST:=REC.AVG_COST;
REC_PIPE.SEC_LONG_NAME:=REC.SEC_LONG_NAME;
REC_PIPE.ISS_CTRY_CD:=REC.ISS_CTRY_CD;
REC_PIPE.RISK_REPORTING_UBR:=REC.RISK_REPORTING_UBR;
REC_PIPE.RISK_COVERING_BRANCH_CCDB:=REC.RISK_COVERING_BRANCH_CCDB;
REC_PIPE.CLEARING_STATUS:=REC.CLEARING_STATUS;
REC_PIPE.FCL_CPTY_SK:=REC.FCL_CPTY_SK;
REC_PIPE.STRGRP:=REC.STRGRP;
REC_PIPE.OPEN_ENDED_FLAG:=REC.OPEN_ENDED_FLAG;
REC_PIPE.AVAILABILITY_IND:=REC.AVAILABILITY_IND;
REC_PIPE.ESCRW_FLG:=REC.ESCRW_FLG;
REC_PIPE.ESTABLISHED_RELP_FLG:=REC.ESTABLISHED_RELP_FLG;
REC_PIPE.GOV_GTY_AMT:=REC.GOV_GTY_AMT;
REC_PIPE.BUBA_CTRY_ID:=REC.BUBA_CTRY_ID;
REC_PIPE.GOV_GTY_CTRY_CD:=REC.GOV_GTY_CTRY_CD;
REC_PIPE.INTERNET_DPST_FLG:=REC.INTERNET_DPST_FLG;
REC_PIPE.LAST_ACTIVITY_DT:=REC.LAST_ACTIVITY_DT;
REC_PIPE.NOTICE_PERIOD_QTY:=REC.NOTICE_PERIOD_QTY;
REC_PIPE.OPR_RELP_FLG:=REC.OPR_RELP_FLG;
REC_PIPE.SIG_WD_PENALTY_FLG:=REC.SIG_WD_PENALTY_FLG;
REC_PIPE.TRN_ACT_FLG:=REC.TRN_ACT_FLG;
PIPE ROW(REC_PIPE);
END LOOP;
the Stored procedre returns REC_PIPE.
I thins this could be not efficient enough...
What do you think?

Best way to store big amount of data

Similar Messages

Maybe you are looking for