InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comWed, 22 May 2013 14:53:00 GMT20http://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspx[quote][b]runal_jagtap (3/19/2013)[/b][hr]Jeff, No we would never need a data a month old, incase if someone needs the data we can retrieve it from Archive DB..but whats the best approach???:w00t:[/quote]Would it in this case not be easiest to backup the data on a predetermined basis to removal media for storage and truncate the source tables?Mon, 25 Mar 2013 07:18:34 GMTkevaburghttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspx[quote][b]Vedran Kesegic (3/25/2013)[/b][hr]You do not need a view for delete-insert command. Making the code even simpler:[code="sql"]INSERT INTO destinationSELECT *FROM( DELETE TOP (100) FROM source OUTPUT DELETED.*) AS t[/code]...[/quote]Thanks for that. And yes I'm kicking myself for missing this alternative.Mon, 25 Mar 2013 06:50:05 GMTSteve JPhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxYou do not need a view for delete-insert command. Making the code even simpler:[code="sql"]INSERT INTO destinationSELECT *FROM( DELETE TOP (100) FROM source OUTPUT DELETED.*) AS t[/code]Complete example:[code="sql"]use tempdbGO-- prepare test data to transferselect id = o.object_id, o.nameinto sourcefrom sys.all_objects o-- prepare destination tableselect *into destinationfrom sourcewhere 1=0 -- impossible conditionGO-- start moving the rowsdeclare @source_rows int, @destination_rows int, @rows int, @rows_per_batch int=1000set nocount onWHILE 1=1 BEGIN -- Print number of rows select @source_rows = sum(p.rows) from sys.partitions p where p.object_id = object_id('dbo.source') select @destination_rows = sum(p.rows) from sys.partitions p where p.object_id = object_id('dbo.destination') RAISERROR('source_rows = %d, destination_rows = %d', 10,1, @source_rows, @destination_rows) WITH NOWAIT IF @rows < @rows_per_batch BREAK -- Let's do the move, babe! INSERT INTO destination(id, name) SELECT t.id, name FROM ( DELETE TOP (@rows_per_batch) FROM source OUTPUT DELETED.* ) AS t SET @rows = @@ROWCOUNTENDGO/* -- cleanupdrop table source, destination*/[/code]Output:[code="plain"]source_rows = 2002, destination_rows = 0source_rows = 1002, destination_rows = 1000source_rows = 2, destination_rows = 2000source_rows = 0, destination_rows = 2002[/code]Mon, 25 Mar 2013 06:00:07 GMTVedran Kesegichttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxA simple and quick way to archive data. [code="sql"]-- Simple table to populate with dataCREATE TABLE [dbo].[Current MPANs] ( [MPAN] [char](13) NOT NULL PRIMARY KEY )CREATE TABLE [dbo].[Old MPANs] ([MPAN] [char](13) NOT NULL PRIMARY KEY )gocreate view [Archive MPANs]as Select top 10 MPAN from dbo.[Current MPANs] order by MPAN goDelete from [Archive MPANs] output deleted.MPAN into [Old MPANs]( MPAN)goselect count(*) from [Current MPANs]select count(*) from [Old MPANs][/code]With this type of method an index is needed to make certain that a table scan isn't done every time the view is called.If this is scheduled to run every minute then the impact on the server is small. Check the query plan to see what is happening. But consider that there are over 43K minutes each month so 23 rows a minute will equate to 1 million records. Having worked on VLDBs (or they were considered to be at the time) not all solutions need the big bang approach ;-)Mon, 25 Mar 2013 05:28:58 GMTSteve JPhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspx[quote][b]Jeff Moden (3/24/2013)[/b][hr][quote][b]Steven Willis (3/24/2013)[/b][hr]I'm in the middle of an archiving project right now. The customer has a single database instance on a shared server with a major host and isn't running enterprise edition so this limited my options greatly.My basic concept is to export the data to be archived to a separate table with a constraint on the last updated date column that covers the time period to be archived. Then, I add the table to a partitioned view that can be queried without knowing which base table is involved. To make matters more complicated, the archival data must be "split" so that any personal data is in one encrypted base table and related information that has no personally identifiable information goes into a second table. The tables are related by a uniqueidentifier that only exists in the two archive tables. Once archived, the underlying tables are read-only. The data in the view can be queried via a stored procedure that has the month and year as parameters.The final step after creating the archive and moving over the data is to delete the rows from the production tables. This step is not to be taken lightly! So when I create the archive tables I create a flag on the production tables that they are only virtually "deleted." Then I compare the two new archive tables against the rows that have been "virtually" deleted and make sure that the numbers and data all add up. Only then are the original rows physically deleted. All of this is done within a transaction so that if something goes haywire it will get rolled back. [/quote]Good documentary on what you do for archiving. I do have to ask though.... you mention the split for personal information and that you (if I'm reading this correctly) then encrypt the personal data and store it in a separate table. My question would be, why isn't that data encrypted in the original table to begin with?[/quote]The sensitive data in the original table is encrypted (or at least it will be). This client has been collecting data for his health-care related business and "suddenly" realized he might have a problem with HIPPA compliance. ;-)However, in addition to the personal health information (PHI), there is a second set of data which consists of more than a hundred questions all of which are yes/no or have some scalar-value response that could never be directly associated to an individual unless they also had access to the encrypted table which has the uniqueidentifier FK. By separating this second set of data from the PHI the access control for reporting and analysis can be granted to users who don't need to see who the data was originally connected to. Also, performance is enhanced because it isn't necessary to encrypt the data. (Hmmmm...maybe I could take all those question responses, concatenate them into a delimited string and store them in a single column and use DelimitedSplit8K to query them...just kidding!)If this client had the resources to do so, it would certainly be best practice to put this "cleaned" data on a completely different server or at least a different database instance so if the tables were compromised it would still be several degrees of separation from the sensitive PHI. Working in a shared hosting environment on non-Enterprise Edition instances without full sysadmin privileges requires a lot of workarounds. There have been cases when my only SQL access was via a host company's interface--yuk! But that is mostly the SQL world I live in.Another purpose for separating the data is due to poor query performance resulting from the original design of the client's database tables. The table holding the PHI and the form question responses is in one ridiculously wide table with over 150 columns. Unfortunately I have no control over that since the data comes from a third-party application. So the best that I could do is manipulate the data myself. With all but the active and most recent data moved to the archive tables, the performance of the existing wide table is significantly improved. If a search of the archive is required it would only be on the encrypted table with the PHI (by users with proper credentials of course). That encrypted PHI archive table only has about 15 columns and by creating a partitioned view by month the query performance on searches goes from something like 30 seconds down to 1 sec. If then the user wants to see the details for one individual row, a separate query will retrieve the detail data. But then it is only pulling in the one related row and not querying 25,000 rows x 150 columns. For all of this I had to write the search query procedures so that the PHI will only be displayed encrypted except for a search column (such as name) or be completely unencrypted depending on the user's credentials. Sun, 24 Mar 2013 18:17:34 GMTSteven Willishttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspx[quote][b]Steven Willis (3/24/2013)[/b][hr]I'm in the middle of an archiving project right now. The customer has a single database instance on a shared server with a major host and isn't running enterprise edition so this limited my options greatly.My basic concept is to export the data to be archived to a separate table with a constraint on the last updated date column that covers the time period to be archived. Then, I add the table to a partitioned view that can be queried without knowing which base table is involved. To make matters more complicated, the archival data must be "split" so that any personal data is in one encrypted base table and related information that has no personally identifiable information goes into a second table. The tables are related by a uniqueidentifier that only exists in the two archive tables. Once archived, the underlying tables are read-only. The data in the view can be queried via a stored procedure that has the month and year as parameters.The final step after creating the archive and moving over the data is to delete the rows from the production tables. This step is not to be taken lightly! So when I create the archive tables I create a flag on the production tables that they are only virtually "deleted." Then I compare the two new archive tables against the rows that have been "virtually" deleted and make sure that the numbers and data all add up. Only then are the original rows physically deleted. All of this is done within a transaction so that if something goes haywire it will get rolled back. [/quote]Good documentary on what you do for archiving. I do have to ask though.... you mention the split for personal information and that you (if I'm reading this correctly) then encrypt the personal data and store it in a separate table. My question would be, why isn't that data encripted in the original table to begin with?Sun, 24 Mar 2013 13:31:34 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxI'm in the middle of an archiving project right now. The customer has a single database instance on a shared server with a major host and isn't running enterprise edition so this limited my options greatly.My basic concept is to export the data to be archived to a separate table with a constraint on the last updated date column that covers the time period to be archived. Then, I add the table to a partitioned view that can be queried without knowing which base table is involved. To make matters more complicated, the archival data must be "split" so that any personal data is in one encrypted base table and related information that has no personally identifiable information goes into a second table. The tables are related by a uniqueidentifier that only exists in the two archive tables. Once archived, the underlying tables are read-only. The data in the view can be queried via a stored procedure that has the month and year as parameters.The final step after creating the archive and moving over the data is to delete the rows from the production tables. This step is not to be taken lightly! So when I create the archive tables I create a flag on the production tables that they are only virtually "deleted." Then I compare the two new archive tables against the rows that have been "virtually" deleted and make sure that the numbers and data all add up. Only then are the original rows physically deleted. All of this is done within a transaction so that if something goes haywire it will get rolled back. Sun, 24 Mar 2013 11:56:38 GMTSteven Willishttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxRight, BULK INSERT, or sp_OA, or SQLCLR, and maybe some other things that could be initiated from the server that I didn't bother mentioning. I still disagree with you on the point of 'xp_cmdshell is not a security risk' but that's OK. For me, SSIS would bridge the 'instance gap' and allow us to move data across the network without initiating file system access from within the database engine, a "win" from my perspective.Sat, 23 Mar 2013 20:06:40 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspx[quote][b]opc.three (3/21/2013)[/b][hr]In this case SSIS is a good choice regardless of the complexity of the tranformation because the source and destination databases are going to be on different instances.If you want to stay in T-SQL your choices become Linked Servers or xp_cmdshell. Personally I would continue down the path of implementing an SSIS Package to do the archiving.[/quote]I have to both agree and disagree there. It's no more difficult to setup a linked server than it is to setup an extra connection in SSIS. So far as importing data from a non-database source on another server goes, there's no need for either a linked server or xp_CmdShell. A simple shared drive and trusted connections along with BULK INSERT will do fine for what most people want or need to do.On the subject of xp_CmdShell, if someone get's the heebie-geebies at the mere mention of xp_CmdShell or a trusted OPENQUERY that uses ACE drivers, then SSIS is definitely the way to go. Since we've been on that subject before, I'll remind folks that xp_CmdShell isn't a security risk. Bad security is a security risk because any hacker that get's into your system with "SA" privs is going to change your career by using xp_CmdShell whether you have it turned off or not.Sat, 23 Mar 2013 19:24:17 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspx[quote][b]david.alcock (3/22/2013)[/b][hr][quote][b]Jeff Moden (3/21/2013)[/b][hr][quote][b]david.alcock (3/21/2013)[/b][hr]SSIS is normally utilised when the copy/move is complex, if it involves data transformations, validations etc.[/quote]I'll go ahead an disagree with that. I've built some killed ETL systems that would logon to FTP, download only what was needed, mark what was downloaded, import the data, transform it, validate it, and merge it with the final tables all using just T-SQL including some rather crazy "don't know how many columns there are in the import" functionality using data imported from Double-Click.net.ETL is just not that difficult. It's ok to use SSIS for this type of stuff but I haven't actually found a need for it. I've even been able to do parallel loads without it.[/quote]When a guy like Jeff starts off with saying 'I'm going to disagree with that' you know you're in trouble, well I get that feeling of dread anyway!!!! :-)Of course you're absolutely right, you can implement all kinds of magic using T-SQL. My suggestion was more based on the requirement here and not a generalisation, if it involves some level of complexity then SSIS would be a way of implementing the process rather simply (like a lookup task or something).[/quote]Heh... sorry, David. I didn't intend to make anyone nervous. Like you, I was making a mostly general statement. I'm just amazed at how many people make it seem like you have to use something like SSIS to do even the simplest of IO tasks. Perhaps the greatest irony of them all is the fact that many people will call a stored procedure from SSIS to accomplish their SSIS task but will still insist that SSIS is the only way to go for "complex" things.Sat, 23 Mar 2013 18:51:04 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspx[quote][b]Jeff Moden (3/21/2013)[/b][hr][quote][b]david.alcock (3/21/2013)[/b][hr]SSIS is normally utilised when the copy/move is complex, if it involves data transformations, validations etc.[/quote]I'll go ahead an disagree with that. I've built some killed ETL systems that would logon to FTP, download only what was needed, mark what was downloaded, import the data, transform it, validate it, and merge it with the final tables all using just T-SQL including some rather crazy "don't know how many columns there are in the import" functionality using data imported from Double-Click.net.ETL is just not that difficult. It's ok to use SSIS for this type of stuff but I haven't actually found a need for it. I've even been able to do parallel loads without it.[/quote]When a guy like Jeff starts off with saying 'I'm going to disagree with that' you know you're in trouble, well I get that feeling of dread anyway!!!! :-)Of course you're absolutely right, you can implement all kinds of magic using T-SQL. My suggestion was more based on the requirement here and not a generalisation, if it involves some level of complexity then SSIS would be a way of implementing the process rather simply (like a lookup task or something).Fri, 22 Mar 2013 10:50:41 GMTdavid.alcockhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxI am stuck at the end partplease refer below linkhttp://www.sqlservercentral.com/articles/Integration+Services+(SSIS)/75331/I have everything uptill ---(Let's continue building the incremental load. )I did build incremental load but new rows is not getting transffered :w00t:pleaes help :crying:Fri, 22 Mar 2013 05:05:51 GMTOnlyOneRJhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxIn this case SSIS is a good choice regardless of the complexity of the tranformation because the source and destination databases are going to be on different instances.If you want to stay in T-SQL your choices become Linked Servers or xp_cmdshell. Personally I would continue down the path of implementing an SSIS Package to do the archiving.[quote]My Task is mentioned belwo..Copy all data from Source to destination DBEvery month only the updated or new data needs to be transffered to destination..Will SSIS help in this? [/quote]In order to retrieve 'only the updated or new data' you will need to know something about each row that you can use to derive whether it was updated or new. And what about deletes?Typical columns used to determine new or modified rows include 'created date' or 'last updated date' columns. Do you have one or both of those, and are they reliable?A rock solid way to do this, although it introduces more DBA work, is to leverage either Change Tracking or Change Data Capture. Those two features work at the database-engine-level to track which rows have changed.Thu, 21 Mar 2013 13:23:23 GMTopc.threehttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspx[quote][b]david.alcock (3/21/2013)[/b][hr]SSIS is normally utilised when the copy/move is complex, if it involves data transformations, validations etc.[/quote]I'll go ahead an disagree with that. I've built some killed ETL systems that would logon to FTP, download only what was needed, mark what was downloaded, import the data, transform it, validate it, and merge it with the final tables all using just T-SQL including some rather crazy "don't know how many columns there are in the import" functionality using data imported from Double-Click.net.ETL is just not that difficult. It's ok to use SSIS for this type of stuff but I haven't actually found a need for it. I've even been able to do parallel loads without it.Thu, 21 Mar 2013 12:07:32 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspx[quote][b]runal_jagtap (3/21/2013)[/b][hr]Jeff, Yup The Srever & the Database would be different...Why it would be overkill :w00t: explain me.. coz i am going to do it.. i dont know how to do it..[/quote]If you've already decided to use SSIS, then my suggestion of making a simple job do a simple insert to the archive and a simple delete from the source would probably underwhelm everyone's gumption. Like I said, doing this through SSIS is real overkill.Thu, 21 Mar 2013 12:02:46 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxMy Task is mentioned belwo..Copy all data from Source to destination DBEvery month only the updated or new data needs to be transffered to destination..Will SSIS help in this?Thu, 21 Mar 2013 03:56:50 GMTOnlyOneRJhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxSSIS is normally utilised when the copy/move is complex, if it involves data transformations, validations etc.Thu, 21 Mar 2013 03:51:43 GMTdavid.alcockhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxJeff, Yup The Srever & the Database would be different...Why it would be overkill :w00t: explain me.. coz i am going to do it.. i dont know how to do it..Thu, 21 Mar 2013 02:27:16 GMTOnlyOneRJhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspx[quote][b]runal_jagtap (3/19/2013)[/b][hr]Thanks Jeff :-)Currently me planning to go with SSIS Package Automation...Well see how i succedd.. incase any query i will come here again.. stating65 views & 0 replies :w00t: ( :-D )[/quote]So, what's the plan? Will the archive table be in a different database or the same database> I'm asking because although SSIS will certainly do the job, it seems like real overkill.Tue, 19 Mar 2013 09:40:24 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxThanks Jeff :-)Currently me planning to go with SSIS Package Automation...Well see how i succedd.. incase any query i will come here again.. stating65 views & 0 replies :w00t: ( :-D )Tue, 19 Mar 2013 08:21:00 GMTOnlyOneRJhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxOne very effective approach would be to "partition" the table but that's only if you have the Enterprise Edition and, IIRC, if you don't mind the "archive" being in the same database. What that will do for you is make it almost instant to "archive" a previous month and it will reduce the nightly maintenance because you won't have to rebuild or reorganize the idexes for the entire table because, if you do it right, the indexes are partitioned, as well.Tue, 19 Mar 2013 07:56:20 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxJeff, No we would never need a data a month old, incase if someone needs the data we can retrieve it from Archive DB..but whats the best approach???:w00t:Tue, 19 Mar 2013 06:09:34 GMTOnlyOneRJhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspx[quote][b]runal_jagtap (3/18/2013)[/b][hr]Example - We have a DB which have loads of data & we want to archiev it to some Server in such a way thatScenario - Source DB have 5 yrs Data in it, we want to move the 5 yrs Data to Destination DB, & then will keep only one month data in Source DB, that means on monthly basis we will have less data in Sorce DB.Please help me a best approach??[/quote]Will you ever have the need to access the data that's more than a month old through a GUI or stored procedure?Mon, 18 Mar 2013 17:56:35 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspx[quote][b]runal_jagtap (3/18/2013)[/b][hr]4 View ... 0 replies :w00t:[/quote]14 minutes... broad subject. Need more patience. ;-)Mon, 18 Mar 2013 17:51:38 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxWell we were mainly moving to new structures so the migration was two part, moving recent data to a faster server and the older data shifted to cheaper archive storage. SSIS was utilised in very simple form, a data flow with source, destination and lookup tasks were the main components as well as script tasks for some customisation. Lookup tasks are very handy for incremental loads as you may be doing.Highly recommend you give this a read if you havent already: [url]http://www.sqlservercentral.com/articles/Stairway+Series/76390/[/url]We didnt have enterprise otherwise I would have implemented some form of partitioning for sure.Mon, 18 Mar 2013 14:55:18 GMTdavid.alcockhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspx[quote][b]Grant Fritchey (3/18/2013)[/b][hr]If you can make changes to your architecture, you might want to look into partitioning the data.[/quote]You can't switch partition to a switching table that is in different database. Switching table and partition must reside on the same filegroup in order for switch partitions to work.The only benefit would be much faster delete (drop partition) of the data you already copied - worth using.I would do a partition switch, bcp-out switching table to a file in native format, bcp-in that file to destination db switching table, and then switch that into destination partitioned table. That is by far the fastest method.Mon, 18 Mar 2013 08:50:44 GMTVedran Kesegichttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspx[quote][b]david.alcock (3/18/2013)[/b][hr]Apologies, I am not sure what you are asking.If it what action to take next, then it depends on the requirements of the business perhaps. Is the data that you have moved still 'active', if so then yes you want the up to date data on there and perhaps some form of audit trail to determine the changes. As for saving the package, there is a specific area in msdb for packages that you can utilise when saving packages.[/quote]David, can you tell me how did u perform this activity via SSIS... please explain in details Mon, 18 Mar 2013 08:43:41 GMTOnlyOneRJhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxApologies, I am not sure what you are asking.If it what action to take next, then it depends on the requirements of the business perhaps. Is the data that you have moved still 'active', if so then yes you want the up to date data on there and perhaps some form of audit trail to determine the changes. As for saving the package, there is a specific area in msdb for packages that you can utilise when saving packages.Mon, 18 Mar 2013 08:10:11 GMTdavid.alcockhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxI did a Import export activity for transfeering the Tables/data to other DB/server and saved the Packgae as SSIS package to the File Location..Now how do i move ahead...1) Tables & data imported to destination server via import export2) SSIS package stored in some location.So the destination server have till date data from source server..after a month how should i nmake changes & execute the package, so that the Only Updated or new data should be imported to destination server :w00t:Mon, 18 Mar 2013 06:15:06 GMTOnlyOneRJhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxIf you can make changes to your architecture, you might want to look into partitioning the data. That makes it very easy to move data out of one database and into another. That's pretty much what it's designed to do. But, it has a number of caveats, the biggest being that you can ensure that retrieval of your data is always going to filter by the same structure that you use to partition the data. If you can't guarantee that, I wouldn't suggest this approach. Otherwise, it's a very viable method. This is an [url=http://msdn.microsoft.com/en-us/library/aa964122(v=SQL.90).aspx]introductory article[/url] from Microsoft. There are other resources online to learn more.Mon, 18 Mar 2013 05:12:48 GMTGrant Fritcheyhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxDavid, can you tell me how did u perform this activity via SSIS... please explain in detailsMon, 18 Mar 2013 04:35:12 GMTOnlyOneRJhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxWe have done similar things in the past, essentially using SSIS to archive/move data to a new server. On enterprise you could partition the data instead.Mon, 18 Mar 2013 04:00:58 GMTdavid.alcockhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspx4 View ... 0 replies :w00t:Mon, 18 Mar 2013 03:52:03 GMTOnlyOneRJhttp://www.sqlservercentral.com/Forums/Topic1432123-391-1.aspxExample - We have a DB which have loads of data & we want to archiev it to some Server in such a way thatScenario - Source DB have 5 yrs Data in it, we want to move the 5 yrs Data to Destination DB, & then will keep only one month data in Source DB, that means on monthly basis we will have less data in Sorce DB.Please help me a best approach??Mon, 18 Mar 2013 03:39:42 GMTOnlyOneRJ