headers
Kyle Simpson | 4 Feb 2003 23:12
Picon
Favicon

- general question about using unixODBC to connect to Access...

I am a web developer, and I host several virtual-hosted sites on a linux 
server. Until now, I have been using PHP and MySQL for these sites, but I 
now have the occassion to need ASP and Access support. I am going to be 
using something like Sun's Chili! ASP software to provide the ASP support, 
but I am wondering how I will actually be able to have an Access database on 
my linux server, and have ASP communicate with it. Is unixODBC sufficient 
for ASP to communicate directly to an access database file (like blah.mdb), 
or is there some other component I am missing in my thought process?  Any 
answers or suggestions on this matter would be greatly appreciated.  Thank 
you!

Kyle Simpson

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Permalink | Reply | 1 comment |
headers
Nick Gorham | 5 Feb 2003 10:57
Favicon

Re: - general question about using unixODBC to connect to Access...

Kyle Simpson wrote:
> I am a web developer, and I host several virtual-hosted sites on a linux 
> server. Until now, I have been using PHP and MySQL for these sites, but 
> I now have the occassion to need ASP and Access support. I am going to 
> be using something like Sun's Chili! ASP software to provide the ASP 
> support, but I am wondering how I will actually be able to have an 
> Access database on my linux server, and have ASP communicate with it. Is 
> unixODBC sufficient for ASP to communicate directly to an access 
> database file (like blah.mdb), or is there some other component I am 
> missing in my thought process?  Any answers or suggestions on this 
> matter would be greatly appreciated.  Thank you!

Hi,

Not good news, the MS Access MDB format is undocumented and subject to 
change at MS's whim, so its a uphill battle to decipher. There is some 
work on this (on sourceforge) but its very beta at the moment.

Do the MDB's have to be on linux ?

--

-- 
Nick Gorham
Easysoft Limited http://www.easysoft.com
Permalink | Reply | 0 comments |
headers
Kyle Simpson | 5 Feb 2003 15:49
Picon
Favicon

Re: - general question about using unixODBC to connect to Access...

I currently only have a Linux webserver in place, and so to run the Access 
database, I need it to be available on that server as well, just like MySQL 
and such are.  It may be in the future that I can use like a bridge ODBC 
driver and connect to it remotely on a windows server, but at the moment I 
don't have that capability.

I spoke with a friend of mine and I think we have decided that since noone 
has yet done an open source version of Jet/ADO/etc (possibly java based, 
like Halcyon's efforts to bridge other Microsoft technologies like ASP and 
.NET), then we are going to start just such a project, in the same spirit. 
I'm sure we'll have to obtain licensing rights and all kind of other stuff 
from Microsoft at some point, but we plan to just see where we can go with 
it for now.

Anyone who might be interested in joining this project?  We need people who 
are very familiar with database engines.

Kyle Simpson
KS Infinity Design, Inc.

----Original Message Follows----
From: Nick Gorham <nick <at> easysoft.com>
Reply-To: unixodbc-dev <at> unixodbc.org
To: unixodbc-dev <at> unixodbc.org, mfoxx <at> hotmail.com
Subject: Re: [unixODBC-DEV] - general question about using unixODBC to 
connect to Access...
Date: Wed, 05 Feb 2003 09:57:56 +0000

Kyle Simpson wrote:
>I am a web developer, and I host several virtual-hosted sites on a linux
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter van Heusden | 7 Feb 2003 15:53

- Problems with SQLPutData and MySQL on DEC Tru64 (v. 4 and 5)

Hi

I'm using UnixODBC 2.2.4 (running under OTL) to access a MySQL database,
via MyODBC 3.51.05. The operating system is Compaq Tru 64, version 4 and
version 5 (same behaviour on both oses).

I'm experiencing a problem in that when I put data into a 'longtext' field
(ODBC datatype SQL_LONGVARCHAR), using SQLPutData, I get nulls inserted
into the field. This problem seems to be occurring in MyODBC (in
a realloc call), but before I take my problem there, I want to check:
has anyone seen such a big using UnixODBC before?

Thanks for any info,
Peter
--

-- 
_______________/\/eGenetics.com\/\_____________________________________
Peter van Heusden    1024D/0517502B		pvh <at> egenetics.com
Electric Genetics    DE5B 6EAA 28AC 57F7 58EF  9295 6A26 6A92 0517 502B
Permalink | Reply | 4 comments |
headers
martin | 7 Feb 2003 16:01
Favicon

RE: - Problems with SQLPutData and MySQL on DEC Tru64 (v. 4 and 5)


On 07-Feb-2003 Peter van Heusden wrote:
> Hi
> 
> I'm using UnixODBC 2.2.4 (running under OTL) to access a MySQL database,
> via MyODBC 3.51.05. The operating system is Compaq Tru 64, version 4 and
> version 5 (same behaviour on both oses).
> 
> I'm experiencing a problem in that when I put data into a 'longtext' field
> (ODBC datatype SQL_LONGVARCHAR), using SQLPutData, I get nulls inserted
> into the field. This problem seems to be occurring in MyODBC (in
> a realloc call), but before I take my problem there, I want to check:
> has anyone seen such a big using UnixODBC before?

I have code here which calls SQLPutData to insert images into longvarchars in
MS SQL Server through our ODBC-ODBC Bridge and it works with unixODBC 2.2.4.

Martin
--

-- 
Martin J. Evans
Easysoft Ltd, UK
Development
Permalink | Reply | 2 comments |
headers
Peter van Heusden | 7 Feb 2003 16:06

Re: - Problems with SQLPutData and MySQL on DEC Tru64 (v. 4 and 5)

On Fri, Feb 07, 2003 at 03:01:05PM -0000, martin <at> easysoft.com wrote:
> 
> On 07-Feb-2003 Peter van Heusden wrote:
> > Hi
> > 
> > I'm using UnixODBC 2.2.4 (running under OTL) to access a MySQL database,
> > via MyODBC 3.51.05. The operating system is Compaq Tru 64, version 4 and
> > version 5 (same behaviour on both oses).
> > 
> > I'm experiencing a problem in that when I put data into a 'longtext' field
> > (ODBC datatype SQL_LONGVARCHAR), using SQLPutData, I get nulls inserted
> > into the field. This problem seems to be occurring in MyODBC (in
> > a realloc call), but before I take my problem there, I want to check:
> > has anyone seen such a big using UnixODBC before?
> 
> I have code here which calls SQLPutData to insert images into longvarchars in
> MS SQL Server through our ODBC-ODBC Bridge and it works with unixODBC 2.2.4.

Ok, but which operating system are you using?

Peter
Permalink | Reply | 1 comment |
headers
martin | 7 Feb 2003 16:10
Favicon

Re: - Problems with SQLPutData and MySQL on DEC Tru64 (v. 4 and 5)


On 07-Feb-2003 Peter van Heusden wrote:
> On Fri, Feb 07, 2003 at 03:01:05PM -0000, martin <at> easysoft.com wrote:
>> 
>> On 07-Feb-2003 Peter van Heusden wrote:
>> > Hi
>> > 
>> > I'm using UnixODBC 2.2.4 (running under OTL) to access a MySQL database,
>> > via MyODBC 3.51.05. The operating system is Compaq Tru 64, version 4 and
>> > version 5 (same behaviour on both oses).
>> > 
>> > I'm experiencing a problem in that when I put data into a 'longtext' field
>> > (ODBC datatype SQL_LONGVARCHAR), using SQLPutData, I get nulls inserted
>> > into the field. This problem seems to be occurring in MyODBC (in
>> > a realloc call), but before I take my problem there, I want to check:
>> > has anyone seen such a big using UnixODBC before?
>> 
>> I have code here which calls SQLPutData to insert images into longvarchars
>> in
>> MS SQL Server through our ODBC-ODBC Bridge and it works with unixODBC 2.2.4.
> 
> Ok, but which operating system are you using?

Linux.

That is:

Linux machine
=============
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nick Gorham | 7 Feb 2003 16:42
Favicon

Re: - Problems with SQLPutData and MySQL on DEC Tru64 (v. 4 and 5)

Peter van Heusden wrote:
> Hi
> 
> I'm using UnixODBC 2.2.4 (running under OTL) to access a MySQL database,
> via MyODBC 3.51.05. The operating system is Compaq Tru 64, version 4 and
> version 5 (same behaviour on both oses).
> 
> I'm experiencing a problem in that when I put data into a 'longtext' field
> (ODBC datatype SQL_LONGVARCHAR), using SQLPutData, I get nulls inserted
> into the field. This problem seems to be occurring in MyODBC (in
> a realloc call), but before I take my problem there, I want to check:
> has anyone seen such a big using UnixODBC before?

Hmm, not that I have seen, maybe worth asking the MySQL folk about this.

--

-- 
Nick Gorham
Easysoft Limited http://www.easysoft.com
Permalink | Reply | 0 comments |
headers
Steve Langasek | 10 Feb 2003 02:10
Favicon

- Misc. fixes against unixodbc 2.2.4

Hello,

Attached is a patch with a variety of fixes from the Debian packaging of
unixodbc 2.2.4, explained in more detail below.  I'd appreciate it if
these could be integrated into the next release.  I'm particularly
interested in seeing the Makefile.am changes integrated; I'm currently
using automake 1.7 for development (in contrast to the 1.4 used to
generate the Makefiles for 2.2.4), so having to run automake (together
with aclocal) on the unixodbc tree gives me a local diff of 99732 lines,
and it'd be nice to trim that down some. ;)

The changes in this patch include:

- changing 'char' to 'int' in the postgres driver, for better
  portability to platforms where char is an unsigned char.
- unixodbc-2.2.4/Makefile.am: don't create a world-writeable directory
  in $(sysconfdir); this is potentially insecure, and is a decision that
  should be left to the administrator.  Among other things, it lets
  users delete one another's file DSNs.
- configure.in: remove a redundant reference to Drivers/odbc/Makefile,
  which makes autoconf 2.5 barf
- odbcinst/SQLManageDataSources.c: probably not portable -- look for the
  Qt GUI setup lib with the '.1' in the extension, since otherwise
  there's no benefit at all to making this a versioned lib instead of a
  plugin.
- odbcinstQ/Makefile.am: make sure that moc-generated source files are
  *deleted* upon 'make clean', so that they'll be rebuilt properly if
  a different version of moc is installed.
- sqp/yac.y: new versions of bison barf on a missing ';' here.
- and a minor grammar nit: the library name is 'Qt', not 'QT'.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nick Gorham | 10 Feb 2003 10:31
Favicon

Re: - Misc. fixes against unixodbc 2.2.4

Steve Langasek wrote:

Cheers Steve, I will add this in.

> Hello,
> 
> Attached is a patch with a variety of fixes from the Debian packaging of
> unixodbc 2.2.4, explained in more detail below.  I'd appreciate it if
> these could be integrated into the next release.  I'm particularly
> interested in seeing the Makefile.am changes integrated; I'm currently
> using automake 1.7 for development (in contrast to the 1.4 used to
> generate the Makefiles for 2.2.4), so having to run automake (together
> with aclocal) on the unixodbc tree gives me a local diff of 99732 lines,
> and it'd be nice to trim that down some. ;)
> 
> The changes in this patch include:
> 
> - changing 'char' to 'int' in the postgres driver, for better
>   portability to platforms where char is an unsigned char.
> - unixodbc-2.2.4/Makefile.am: don't create a world-writeable directory
>   in $(sysconfdir); this is potentially insecure, and is a decision that
>   should be left to the administrator.  Among other things, it lets
>   users delete one another's file DSNs.
> - configure.in: remove a redundant reference to Drivers/odbc/Makefile,
>   which makes autoconf 2.5 barf
> - odbcinst/SQLManageDataSources.c: probably not portable -- look for the
>   Qt GUI setup lib with the '.1' in the extension, since otherwise
>   there's no benefit at all to making this a versioned lib instead of a
>   plugin.
> - odbcinstQ/Makefile.am: make sure that moc-generated source files are
(Continue reading)

Permalink | Reply | 0 comments |

Gmane