How to setup a development environment for sharepoint 2013

I highly recommend using a VM. SharePoint is big. It requires multiple servers and lots of services. Basically its guaranteed to slow down any workstation you install it on. Other benefits of using a VM to develop:

• Undo disks
• Moving your dev environment from workstation to workstation
• easy back-ups

This is a pretty comprehensive guide to building a full featured SharePoint VM: http://www.pptspaces.com/sharepointreporterblog/Lists/Posts/Post.aspx?List=7537e639%2Db4e5%2D48b6%2D97c0%2Da75e44ee9be3&ID=28&Source=http%3A%2F%2Fwww%2Epptspaces%2Ecom%2Fsharepointreporterblog%2FLists%2FPosts%2FAllPosts%2Easpx

Although, if you are going to be doing a lot of SharePoint development I would build a parent VM with the OS, SharePoint, and database. Then create a child VM (differential disk) with dev tools (VS 2008, Office 2007, SharePoint Designer). That way, you can always roll back to a clean SharePoint environment if you need to.

Furthermore, I think the best way to do serious solution development is to spend the time and learn how to build your own solution files, and rolling your own features. NANT can be used to great effect for this. The existing crop of automated tools have limitations that you will inevitably run up against if you are doing anything a bit complicated.

Learning all of the moving parts of solution development is a bit daunting, but once you do it gives you a MUCH better picture of what SharePoint is doing under the covers.

As far as I know, there is no Oracle supplied package to do this. And I would be skeptical of any 3rd party tool that claims to accomplish this goal, because it's basically impossible.

I once wrote a package like this, and quickly regretted it. It's easy to get something that works 99% of the time, but that last 1% will kill you.

If you really need something like this, and need it to be very accurate, you must tightly control what data is allowed and what tools can be used to run the script. Below is a small fraction of the issues you will face:

• Escaping
• Single inserts are very slow (especially if it goes over a network)
• Combining inserts is faster, but can run into some nasty parsing bugs when you start inserting hundreds of rows
• There are many potential data types, including custom ones. You may only have NUMBER, VARCHAR2, and DATE now, but what happens if someone adds RAW, BLOB, BFILE, nested tables, etc.?
• Storing LOBs requires breaking the data into chunks because of VARCHAR2 size limitations (4000 or 32767, depending on how you do it).
• Character set issues - This will drive you ¿¿¿¿¿¿¿ insane.
• Enviroment limitations - For example, SQL*Plus does not allow more than 2500 characters per line, and will drop whitespace at the end of your line.
• Referential Integrity - You'll need to disable these constraints or insert data in the right order.
• "Fake" columns - virtual columns, XML lobs, etc. - don't import these.
• Missing partitions - If you're not using INTERVAL partitioning you may need to manually create them.
• Novlidated data - Just about any constraint can be violated, so you may need to disable everything.

If you want your data to be accurate you just have to use the Oracle utilities, like data pump and export.