Re: I can attach in SQL Server, but can I in Oracle?

Karsten,

[Quoted] Again, thanks for the feedback.

[Quoted] [Quoted] I have no problem with creating the tables with SQL scripts; it's just the 5,000 rows of data to load with INSERTs. As one person who responded commented, that 5,000 rows being loaded is nothing, it's the creating the 5,000 INSERTS that's the pain in the butt ... but then again someone is probably going to point me to a very easy way in Oracle to do that. That would be nice.

If I already knew how to do that in Oracle I wouldn't need to ask ... and come to think of it, there wouldn't be a need for these newsgroups if everyone knew everything there was to know.

My goal was to find the easiest and cleanest way for my clients to install my application. Without getting into the "which is better? -- SQL Server or Oracle" bashing, I have found that SQL Server -- for better or worse (And please don't start on how bad SQL Server is compared to Oracle) -- is a lot easier to do this with than is Oracle -- And that is NOT intended to be a criticism of Oracle!! And, no, I don't think that Oracle is just a simple replacement for SQL Server -- not all of us are the idiots that some would believe us to be.

I want to give the client's Oracle DBA a clean workable installation that they feel comfortable executing knowing that it won't screw up what they have working.

On "staying current", I do two things to "learn" the latest software tools: First, I am lucky in that I live near Dallas where there is a community college that is highly respected for teaching software classes -- the classes are taught by instructors who do software development at large corporations like EDS, Microsoft, and other high-tech companies for a living and teach classes at night. I have taken every class they offer in C++, VS .NET languages, SQL Server (yes, I also plan to take any classes they offer in Oracle, but not now), etc.

Second, since the Dallas (Irving) office of Microsoft is the largest outside of Redmond, I attend every User Group, SIG and meeting that they have as well.

And in the between time, I work, sleep, work, eat, work, etc. as much as 24-hours a day allows. Oracle is such a big learning curve that I don't have the time or inclination to become a DBA. I only need to know enough to ensure that the application works and doesn't corrupt the databases.

VS.NET is such a different animal for most "developers" that I don't think that they are aware of how differently it interfaces with the databases -- VS uses "disconnected" datasets. So the issue of concurrency is "different" from the situation where you maintain a connection with the server. Since I'm using the managed provider from Oracle, I feel very comfortable in ensuring that a lot of the ".NET issues" related to disconnected datasets have been addressed.

Anyway, from this old timer, thanks for the response.

Also, thanks to all of those others who have provided help and assistance. It is very much appreciated.

BTW, some of the inserted comments above were not addressed to you, but to some of the others who have responded to this thread.

Ron

"Karsten Farrell" <kfarrell_at_belgariad.com> wrote in message news:MPG.199dc9572d8ecfc5989834_at_news.la.sbcglobal.net...
> Hi Ron Fluegge, thanks for writing this:
> > Karsten,
> >
> > Thanks for the response.
> >
> > I'll give "transportable tablespaces" a further look. I found it in
several
> > books that I have, but I thought that there had to be an easier way ...
from
> > the "novice" perspective.
> >
> > Again, thanks...
> >
> > Ron
> >
>
> Don't get me wrong ... there are easier ways. I just picked up on your
> comment about giving the data to the customer using your tablespace
> structure. Most of the other techniques require that your customers
> already have your tablespace structure in their database (or else you'd be
> loading your data into their "default" tablespaces, which may or may not
> be the most efficient). Transportable tablespaces allow your intimate
> knowledge of the data to carry over to the customer site without too much
> "fiddling" on the part of the customer.
>
> I read some of the other posts in this thread and most of what was
> suggested (other than that you stop and become an Oracle expert) would
> require that the customer site go thru a preliminary setup stage to
> prepare to receive your data. For the most part, transportable tablespaces
> sidestep these issues. If you believe Oracle, it's the greatest thing
> since sliced bread. :)
>
> And btw, as one old timer to another, I've been in the IT field for a
> little over 40 years (they didn't call it IT back then) and with Oracle
> for the last 17 or so. Good for you ... staying current ... some of my old
> Fortran and Cobol buddies are still looking for jobs now that Y2K is over.
> --
> [:%s/Karsten Farrell/Oracle DBA/g]
Received on Sat Aug 09 2003 - 01:31:39 CEST