At 4:18 PM -0800 12/4/06, Richard Troy wrote: > >So, now the only problem is understanding how to get it to let me connect >via JDBC as an alternative user. At this point, I don't understand how a >local user gets in when an identical authorization with jdbc doesn't. >Some comment on this would be timely!
Well, if by "local user" you mean someone running say the SQL terminal monitor, one way to characterize the difference is when you start talking Ingres GCA protocol. Anything linking directly with an Ingres library (embedded SQL, stuff using the API such as the ODBC interface, the terminal monitor, etc) probably talks GCA as a client. If you are talking to a local DBMS server, the client can connect directly. If you're remote, the theory is that you talk to a local GCC which talks to a remote GCC which talks to its local DBMS server. You can bypass the GCC's but you lose in terms of machine/network independence and addressability. JDBC (and the .NET stuff too, I believe) doesn't link with an Ingres object code library; it's impractical in several different directions. So, rather than try to write a java implementation of GCA on top of everything else, JDBC talks a simplified protocol. It expects to talk to a DAS server, which can be local or remote (I think! not entirely sure here). The DAS server talks GCA out its other end and from there it looks like a traditional Ingres client. Your connect-by has to go through some extra layers (jdbc and the DAS server), which I suppose is part of what makes it different. Maybe someone who actually uses the connectivity stuff can help you with the mechanics. Karl _______________________________________________ Users mailing list Users@lists.ingres.com http://lists.ingres.com/mailman/listinfo/users
