ODBC

[L. V. Lammert]

OK, .. if the group is now to be Android only (which would be my
preference, but on to pratical matters), allow me to as a good question:

We have an old Palm application that may move to a tablet; due to a number
of reasons, the simplest architecture is if the App can talk directly to
a corporate database via ODBC.

There is an ODBCRouter for IOS/iPad, .. and I see some notes about an
JDBC-ODBC scheme for Android.

Which would be the better architecture?

Lee

[Heath Borders]

Are you asking whether iOS or Android has better ODBC support?

I wrote an ODBC import from a command-line cocoa application that worked well. I used something other than ODBCRouter, and I'll see if I still have notes on a different machine indicating what I did use.

I've never tried to use ODBC from Android.

-Heath Borders
heath....@gmail.com
Twitter: heathborders
http://heath-tech.blogspot.com

--
You received this message because you are subscribed to the Google Groups "STL Mobile Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stl-mobile-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rob Dickerson]

Is the question is between iOS and Android? In that case it probably comes down to which piece of hardware (iPad vs Android tablet) you want to use.

While you can probably set up a networked JDBC-ODBC bridge in Java, it's hard for me to imagine a scenario where you wouldn't want to write at least a thin service / API for the application to use instead. This is more secure, will make it much easier to write new clients, swap out database implementations, etc., and a well-defined service interface is almost certainly going to lead to cleaner and simpler client code.

On Wed, May 14, 2014 at 2:14 PM, L. V. Lammert <lvla...@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "STL Mobile Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stl-mobile-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Rob Dickerson
rc.dic...@gmail.com

[L. V. Lammert]

On Wed, 14 May 2014, Heath Borders wrote:

> Are you asking whether iOS or Android has better ODBC support?
>

Support, experience, impressions, .. it may be important enough to
recommend an Android tablet over iPad, *especially* since apps can be
loaded directly on Andriod without mucking with iTunes.

> I wrote an ODBC import from a command-line cocoa application that worked
> well. I used something other than ODBCRouter, and I'll see if I still have
> notes on a different machine indicating what I did use.
>

Cool - thanks!

Lee

[L. V. Lammert]

On Wed, 14 May 2014, Rob Dickerson wrote:

> Is the question is between iOS and Android? In that case it probably comes
> down to which piece of hardware (iPad vs Android tablet) you want to use.
>

Affirmative.

> While you can probably set up a networked JDBC-ODBC bridge in Java, it's
> hard for me to imagine a scenario where you wouldn't want to write at least
> a thin service / API for the application to use instead.
>

The corporate environment make that almost impossible to get approved, ..
it will be enough of a pain just getting a login on the SQL Server.

> This is more secure, will make it much easier to write new clients, swap
> out database implementations, etc., and a well-defined service interface
> is almost certainly going to lead to cleaner and simpler client code.
>

Normally I would agree, but the data transactions are so simple in this
case that avoiding any server side software at all is realistic, and a big
advantage for these folks (i.e. nothing to maintain; they can't even keep
HotSync running).

Thanks!

Lee >

[Rob Dickerson]

A publicly available ODBC connection counts as something to maintain. :)

        Lee >

--
You received this message because you are subscribed to the Google Groups "STL Mobile Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stl-mobile-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Rob Dickerson
rc.dic...@gmail.com

[L. V. Lammert]

On Wed, 14 May 2014, Rob Dickerson wrote:

> A publicly available ODBC connection counts as something to maintain. :)
>

Not if there isn't any code involved, .. any Windoze admin should be able
to fix credential problems.

Lee

[Rob Dickerson]

I hear what you're saying. Here's why I don't quite agree.

There are lots of maintenance considerations that go along with exposing data in a public way, including making sure the data is exposed reliably and securely. Even though there's no "code" to maintain, the availability and security of an open database connection can be affected by seemingly orthogonal changes to network configurations or database / ODBC configurations. It would be awful to realize that some innocuous looking config change made last month had inadvertently opened the ODBC connection to the entire database up to the general public! Because it exposes data in a much more controlled and limited way, a carefully considered service API is actually much easier to properly maintain than an open database connection.

You're obviously in the best position to know what's best for your client, but this the type of argument I would make to someone pushing back against a proper service for their mobile app.

        Lee

--
You received this message because you are subscribed to the Google Groups "STL Mobile Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stl-mobile-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Rob Dickerson
rc.dic...@gmail.com

[L. V. Lammert]

On Wed, 14 May 2014, Rob Dickerson wrote:

> I hear what you're saying. Here's why I don't quite agree.
>
> There are lots of maintenance considerations that go along with exposing
> data in a public way, including making sure the data is exposed reliably
> and securely. Even though there's no "code" to maintain, the availability
> and security of an open database connection can be affected by seemingly
> orthogonal changes to network configurations or database / ODBC
> configurations. It would be awful to realize that some innocuous looking
> config change made last month had inadvertently opened the ODBC connection
> to the entire database up to the general public! Because it exposes data in
> a much more controlled and limited way, a carefully considered service API
> is actually much easier to properly maintain than an open database
> connection.
>

That is a minor point, .. but there are a lot of opposite arguments:

1) Database security is a totally separate matter, that's why logins are
used [for the app].

2) Data is already exposed on the network for multiple users and
applications, adding a tablet app fits directly into that structure.

3) The management app will also use the same ODBC connection, so it has to
be open anyway.

4) Having to install a driver on a server adds a level of complexity that
requires separate maintenance; the fact that it appears that the iPad app
WOULD required install of a commercial dirver, ODBCRouter, is bad enough,
,.. having to maintain code is another level of complexity that should be
avoided.

Remember, this is an *internal* app, only used inside the corporate WiFi
enviornment. For a company that can't maintain a HotSync app, we need to
REALLY stay simple!

TTFR!

Lee