Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Usenet -> c.d.o.server -> Re: Access migration woes.
> Since you don't seem to be getting any "Oracle" feedback, let me suggest
> that you look at Informix :-)
Thanks I guess Oracle does not do these things or somebody might have piped up.
>
> Object Names : Informix 2000 allows object naming to 128 characters.
Hey great!. What is deal with this anyway it's the year 2000 already. In Postgres I was able to change one #DEFINE and recompile and I was good to go.
>
> Case insensitive searches (Access's DOS feature, I suppose) can be
> accomplished using Informix's built-in string manipulation functions. For
> example,
>
> SELECT ...
> FROM table1, table2
> WHERE UPPER(table1.col1) = UPPER(table2.col1)
I was really hoping to avoid redoing every single query in my application (over a thousand!) either by setting some option in the ODBC driver or the back end database. Somebody suggested I overload the "=" operator in postgres but I am not much of a C++ programmer. The other suggestion was to use regexp searches which would also force me to redo all my queries. Is SQL server the only database that does case insensitive matches?
> For more details on these and the tons of other goodies that Informix
> offers, take a peek at http://www.informix.com/answers/ or fire your
> questions at comp.databases.informix
>
> Rudy
>
> Tim Uckun wrote:
>
> > Hello everybody.
> > I am planning on migrating from Microsoft access toOracle. There are two
> > major hurdles to overcome before I can do this though.
> > One is that Access can have object named up to 255 characters long while
> > Oracle is limited to thirty or so.
> > Two is that Access does not do a case sensitive search in where clauses
> > while Oracle cares about case. In access where field='something' and
> > where field='Something' yield the same results.
> >
> > I am hoping somebody here can tell me how to get around these
> > limitations (features?) of oracle.
> >
> > If these can not be accomplished I may be forced to upsize to SQL server
> > which I am hoping to avoid.
Received on Wed Mar 22 2000 - 00:00:00 CST
![]() |
![]() |