digir-developers — DiGIR Developers

[Digir-dev] yo

[<rut...@ya...>]

digir heres something I found earlier http://www2.news7idaily.com/ talk to you later

[Digir-dev] Hi

[<rut...@ya...>]

digir look into this http://news7review.com/ bye

[Digir-dev] do you need an job... read this

[siva p. <rut...@ya...>]

Helloo how are you today. if you would you like to pull in money on the internet visit http://localusa-times.com/364676/548 it is such an simple...

[Digir-dev] earn money at home today...

[siva p. <rut...@ya...>]

Yello whats happening. if u want to bring in some a income from home try www.readtimesdaily.org/m27zqsv/2615

[Digir-dev] if u need an job give this a try!

[siva p. <rut...@ya...>]

Hey you how goes everything, if you wanna make an income from home try www.usatimesnewsdaily.com/qg0bux?6497

[Digir-dev] Using DiGIR with a proxy

[Matthew B. <M.B...@ke...>]

Hi

This is a follow-up to the message "Configuring DiGIR issue" posted to this list on 2007-11-27[1].

DiGIR uses XPath, which by default can't handle retreiving URLs through a proxy server.

If you have PHP 5.0.0 or greater, edit the file lib/XPath.class.php. In the function importFromFile($fileName), change this line:
        $xmlString = @implode('', @file($fileName);
to this:
        $context = stream_context_create(array('http'=>array('proxy'=>'tcp://proxy:8080',
                                                             'request_fulluri'=>true)));
        $xmlString = @implode('', @file($fileName, false, $context));
(changing proxy:8080 as appropriate).

See http://bugs.php.net/bug.php?id=6701 for further information.

--
Matt Blissett

[1] http://sourceforge.net/mailarchive/message.php?msg_name=DEF541F3CB545B4A8BC9A811132359C03EC72210CA%40KEXCH00.ad.kew.org

Re: [Digir-dev] [tdwg-tag] Recent DiGIR service disruption

[Roderic P. <r....@bi...>]

Dear Roger,


On 8 Oct 2008, at 10:42, Roger Hyam wrote:

> Thanks to Rod and DaveV for their work.
>
> I'd like to make one observation and concur with David Shorthouse on
> one point.
>
> 1) Looking down the list of providers many are exposed as IP addresses
> (which is bad), some are on domain names but not port 80 (which is
> slightly bad) and some are clearly machine names rather than names
> that one would associate with services. It appears to me that a
> proportion people are not using DNS robustly to allow services to be
> moved from machine to machine in a sensible way. So aside from the
> current issues DaveV has outline there is inherent brittleness in the
> way we are implementing these services. This may well be because
> people in large or small institutions do not have easy access to DNS
> configuration for their institutional domain even if they understand
> the importance of it. This has big implications for role out of LSIDs
> or any other technology dependent on configuration of DNS.

I agree that this is a big issue, and mucking with the DNS strikes me  
as the Achilles heel of easy adoption of LSIDs. That said, I think we  
desperately need GUIDs for specimens, if only to enable other  
approaches, such as mirroring data.


>
>
> 2) To concur with DavidS on the number of providers. Whilst
> developing  the Biodiversity Collections Index we worked through some
> lists of DiGIR providers at various portals to see if we were missing
> any 'real' collections. What struck us was the level of overlap and
> the fact that we weren't discovering much (if anything) new. Rod's
> page lists < 200 DiGIR providers (if I try and weed out the duplicates
> by eye).  BCI has around 5,000 physical collections listed. This seems
> like a small percentage of cover even if you take into account BioCASe
> and TAPIR providers. There is overlap between provider and they do not
> very often cover complete collections. On the other hand the more
> important collections may be more likely to be covered.
>

I've  had a few emails about how to update the list of DiGIR (and  
other providers), so the list will change at some point (and grow).  
But you are right, the degree of coverage is pretty low, and I'd  
suggest heavily biased towards terrestrial vertebrates (perhaps  
because of the relatively small collection sizes, and the culture of  
assigning identifiers to individual specimens).

Regards

Rod




> Sorry for the lengthy cross post.
>
> All the best,
>
> Roger
>
>
>
> On 8 Oct 2008, at 07:06, Dave Vieglais wrote:
>
>> Apologies for cross posting.
>>
>> Hopefully, most of you did not notice this, but if you did, here's
>> what happened.  A problem with resolving the digir.net domain was
>> recently identified by John Wieczorek and possibly others.  This
>> problem would have affected most, if not all DiGIR providers  
>> currently
>> operating.  Once identified, the issue was promptly resolved, and
>> ongoing problems are unlikely.
>>
>> This message provides further information about the problem, how it
>> was resolved, and how recurrence will be avoided to ensure continued
>> operation of the DiGIR infrastructure.
>>
>>
>> = Problem =
>>
>> The DNS entry "digir.net" is an A record that must point to an IP
>> address.  For several years digir.net resolved to the ip address of
>> "66.35.250.210" which is a Source Forge machine that is configured as
>> a VHOST for digir.net.  At some point in the last 48hrs,  
>> 66.35.250.210
>> ceased to respond as a VHOST for digir.net.  This meant that any web
>> service that was expecting to retrieve content from digir.net (e.g. http://digir.net/schema/protocol/2003/1.0/digir.xsd
>> ) failed, with significant operational repercussions.  For technical
>> reasons, most other digir.net DNS entries were unaffected (e.g. www.digir.net
>> ).
>>
>>
>> = Resolution =
>>
>> The new Source Forge VHOST servicing www.digir.net was identified as
>> "216.34.181.97", and the DNS entry for digir.net was updated
>> appropriately.  Since the TTL on that DNS record was set relatively
>> short (600 seconds), the DNS infrastructure picked up the new
>> information fairly quickly, and testing indicates that digir.net URLs
>> are now being correctly resolved from several locations around the
>> world.
>>
>>
>> = What You Need To Do =
>>
>> Nothing.  You should not notice any ongoing disruption.
>>
>>
>> = Ensuring Continued Operation =
>>
>> There are three major issues that lead to this malfunction (#2 and #3
>> are informational only for developers of new services and tools):
>>
>> 1. We have no control over Source Forge, and nor should digir.net
>> infrastructure be dependent on them
>>
>> 2. Much of the existing installed DiGIR infrastructure references
>> "digir.net" directly and so DNS level indirection is not practical.
>>
>> 3. HTTP redirects need to be supported in service implementations
>> and their clients.  I suspect that a lot of DiGIR software services
>> and clients do not follow redirects properly.
>>
>>
>> == Issue #1 ==
>>
>> A DNS monitoring service is now in place that will update the DNS
>> entries if the source forge machine changes again.
>>
>> Also, a replica of the DiGIR web material currently hosted by Source
>> Forge is being created on a machine that we have complete control  
>> over
>> and is located on a fast internet backbone.  The replica machine will
>> be monitored with a system that will provide automatic notification  
>> to
>> appropriate contacts in the event of failure.  This machine will be
>> located at the University of Kansas at least initially.  Once
>> operational, the DNS entry for digir.net will be modified to point to
>> this machine.
>>
>> DNS services are handled by dyndns.org.  Since their inception they
>> have provided a 100% uptime for their clients which includes domains
>> such as CNN, Mozilla, and Twitter.  Since digir.net was an early
>> adopter of their services, the DNS service provided by DynDNS does  
>> not
>> expire.  DNS registration does expire however, and this relatively
>> minor expense is covered by the University of Kansas with assistance
>> from the National Science Foundation.
>>
>>
>> == Issue #2 ==
>>
>> In retrospect, something like "http://schema.digir.net" rather than  
>> "http://digir.net
>> " should have been used.  This would have provided a low level (DNS)
>> mechanism for indirection that would have been unaffected by this
>> unanticipated hardware change.  Altering these entries in DiGIR
>> providers and tools is really not practical at this stage, so it is
>> unlikely that this issue can be directly addressed.
>>
>>
>> == Issue #3 ==
>>
>> HTTP offers a mechanism for temporary and permanent redirection.  In
>> order to take advantage of this functionality, it is necessary for
>> HTTP clients to properly interpret the HTTP 301 and 307 status codes
>> and the respective response headers to determine the new location of
>> the resource being resolved.  This is the mechanism employed by PURLs
>> and TinyURL for example.  Unfortunately, many developers take short
>> cuts when building tools to retrieve content from URLs and avoid the
>> additional small amount of work necessary to handle redirect
>> messages.  Where ever possible, developers of services and clients
>> should use libraries that at least properly handle HTTP redirects
>> which will allow the use of PURLs and other mechanisms for providing
>> an additional level of indirection in URL resolution where necessary.
>>
>>
>> regards,
>>  Dave Vieglais
>>
>> ---
>> Biodiversity Research Center
>> University of Kansas
>>
>>
>> _______________________________________________
>> tdwg-tag mailing list
>> tdw...@li...
>> http://lists.tdwg.org/mailman/listinfo/tdwg-tag
>
> -------------------------------------------------------------
> Roger Hyam
> Roger@BiodiversityCollectionsIndex.org
> http://www.BiodiversityCollectionsIndex.org
> -------------------------------------------------------------
> Royal Botanic Garden Edinburgh
> 20A Inverleith Row, Edinburgh, EH3 5LR, UK
> Tel: +44 131 552 7171 ext 3015
> Fax: +44 131 248 2901
> http://www.rbge.org.uk/
> -------------------------------------------------------------
>
>
>
>
> _______________________________________________
> tdwg-tag mailing list
> tdw...@li...
> http://lists.tdwg.org/mailman/listinfo/tdwg-tag
>

---------------------------------------------------------
Roderic Page
Professor of Taxonomy
DEEB, FBLS
Graham Kerr Building
University of Glasgow
Glasgow G12 8QQ, UK

Email: r....@bi...
Tel: +44 141 330 4778
Fax: +44 141 330 2792
AIM: rod...@ai...
Facebook: http://www.facebook.com/profile.php?id=1112517192
Twitter: http://twitter.com/rdmpage
Blog: http://iphylo.blogspot.com
Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html

Re: [Digir-dev] [tdwg-tag] Recent DiGIR service disruption

[Roger H. <rog...@ma...>]

Thanks to Rod and DaveV for their work.

I'd like to make one observation and concur with David Shorthouse on  
one point.

1) Looking down the list of providers many are exposed as IP addresses  
(which is bad), some are on domain names but not port 80 (which is  
slightly bad) and some are clearly machine names rather than names  
that one would associate with services. It appears to me that a  
proportion people are not using DNS robustly to allow services to be  
moved from machine to machine in a sensible way. So aside from the  
current issues DaveV has outline there is inherent brittleness in the  
way we are implementing these services. This may well be because  
people in large or small institutions do not have easy access to DNS  
configuration for their institutional domain even if they understand  
the importance of it. This has big implications for role out of LSIDs  
or any other technology dependent on configuration of DNS.

2) To concur with DavidS on the number of providers. Whilst  
developing  the Biodiversity Collections Index we worked through some  
lists of DiGIR providers at various portals to see if we were missing  
any 'real' collections. What struck us was the level of overlap and  
the fact that we weren't discovering much (if anything) new. Rod's  
page lists < 200 DiGIR providers (if I try and weed out the duplicates  
by eye).  BCI has around 5,000 physical collections listed. This seems  
like a small percentage of cover even if you take into account BioCASe  
and TAPIR providers. There is overlap between provider and they do not  
very often cover complete collections. On the other hand the more  
important collections may be more likely to be covered.

Sorry for the lengthy cross post.

All the best,

Roger



On 8 Oct 2008, at 07:06, Dave Vieglais wrote:

> Apologies for cross posting.
>
> Hopefully, most of you did not notice this, but if you did, here's
> what happened.  A problem with resolving the digir.net domain was
> recently identified by John Wieczorek and possibly others.  This
> problem would have affected most, if not all DiGIR providers currently
> operating.  Once identified, the issue was promptly resolved, and
> ongoing problems are unlikely.
>
> This message provides further information about the problem, how it
> was resolved, and how recurrence will be avoided to ensure continued
> operation of the DiGIR infrastructure.
>
>
> = Problem =
>
> The DNS entry "digir.net" is an A record that must point to an IP
> address.  For several years digir.net resolved to the ip address of
> "66.35.250.210" which is a Source Forge machine that is configured as
> a VHOST for digir.net.  At some point in the last 48hrs, 66.35.250.210
> ceased to respond as a VHOST for digir.net.  This meant that any web
> service that was expecting to retrieve content from digir.net (e.g. http://digir.net/schema/protocol/2003/1.0/digir.xsd
>  ) failed, with significant operational repercussions.  For technical
> reasons, most other digir.net DNS entries were unaffected (e.g. www.digir.net
> ).
>
>
> = Resolution =
>
> The new Source Forge VHOST servicing www.digir.net was identified as
> "216.34.181.97", and the DNS entry for digir.net was updated
> appropriately.  Since the TTL on that DNS record was set relatively
> short (600 seconds), the DNS infrastructure picked up the new
> information fairly quickly, and testing indicates that digir.net URLs
> are now being correctly resolved from several locations around the
> world.
>
>
> = What You Need To Do =
>
> Nothing.  You should not notice any ongoing disruption.
>
>
> = Ensuring Continued Operation =
>
> There are three major issues that lead to this malfunction (#2 and #3
> are informational only for developers of new services and tools):
>
>  1. We have no control over Source Forge, and nor should digir.net
> infrastructure be dependent on them
>
>  2. Much of the existing installed DiGIR infrastructure references
> "digir.net" directly and so DNS level indirection is not practical.
>
>  3. HTTP redirects need to be supported in service implementations
> and their clients.  I suspect that a lot of DiGIR software services
> and clients do not follow redirects properly.
>
>
> == Issue #1 ==
>
> A DNS monitoring service is now in place that will update the DNS
> entries if the source forge machine changes again.
>
> Also, a replica of the DiGIR web material currently hosted by Source
> Forge is being created on a machine that we have complete control over
> and is located on a fast internet backbone.  The replica machine will
> be monitored with a system that will provide automatic notification to
> appropriate contacts in the event of failure.  This machine will be
> located at the University of Kansas at least initially.  Once
> operational, the DNS entry for digir.net will be modified to point to
> this machine.
>
> DNS services are handled by dyndns.org.  Since their inception they
> have provided a 100% uptime for their clients which includes domains
> such as CNN, Mozilla, and Twitter.  Since digir.net was an early
> adopter of their services, the DNS service provided by DynDNS does not
> expire.  DNS registration does expire however, and this relatively
> minor expense is covered by the University of Kansas with assistance
> from the National Science Foundation.
>
>
> == Issue #2 ==
>
> In retrospect, something like "http://schema.digir.net" rather than "http://digir.net
> " should have been used.  This would have provided a low level (DNS)
> mechanism for indirection that would have been unaffected by this
> unanticipated hardware change.  Altering these entries in DiGIR
> providers and tools is really not practical at this stage, so it is
> unlikely that this issue can be directly addressed.
>
>
> == Issue #3 ==
>
> HTTP offers a mechanism for temporary and permanent redirection.  In
> order to take advantage of this functionality, it is necessary for
> HTTP clients to properly interpret the HTTP 301 and 307 status codes
> and the respective response headers to determine the new location of
> the resource being resolved.  This is the mechanism employed by PURLs
> and TinyURL for example.  Unfortunately, many developers take short
> cuts when building tools to retrieve content from URLs and avoid the
> additional small amount of work necessary to handle redirect
> messages.  Where ever possible, developers of services and clients
> should use libraries that at least properly handle HTTP redirects
> which will allow the use of PURLs and other mechanisms for providing
> an additional level of indirection in URL resolution where necessary.
>
>
> regards,
>   Dave Vieglais
>
> ---
> Biodiversity Research Center
> University of Kansas
>
>
> _______________________________________________
> tdwg-tag mailing list
> tdw...@li...
> http://lists.tdwg.org/mailman/listinfo/tdwg-tag

-------------------------------------------------------------
Roger Hyam
Roger@BiodiversityCollectionsIndex.org
http://www.BiodiversityCollectionsIndex.org
-------------------------------------------------------------
Royal Botanic Garden Edinburgh
20A Inverleith Row, Edinburgh, EH3 5LR, UK
Tel: +44 131 552 7171 ext 3015
Fax: +44 131 248 2901
http://www.rbge.org.uk/
-------------------------------------------------------------

[Digir-dev] Recent DiGIR service disruption

[Dave V. <vie...@ku...>]

Apologies for cross posting.

Hopefully, most of you did not notice this, but if you did, here's  
what happened.  A problem with resolving the digir.net domain was  
recently identified by John Wieczorek and possibly others.  This  
problem would have affected most, if not all DiGIR providers currently  
operating.  Once identified, the issue was promptly resolved, and  
ongoing problems are unlikely.

This message provides further information about the problem, how it  
was resolved, and how recurrence will be avoided to ensure continued  
operation of the DiGIR infrastructure.


= Problem =

The DNS entry "digir.net" is an A record that must point to an IP  
address.  For several years digir.net resolved to the ip address of  
"66.35.250.210" which is a Source Forge machine that is configured as  
a VHOST for digir.net.  At some point in the last 48hrs, 66.35.250.210  
ceased to respond as a VHOST for digir.net.  This meant that any web  
service that was expecting to retrieve content from digir.net (e.g. http://digir.net/schema/protocol/2003/1.0/digir.xsd 
  ) failed, with significant operational repercussions.  For technical  
reasons, most other digir.net DNS entries were unaffected (e.g. www.digir.net 
).


= Resolution =

The new Source Forge VHOST servicing www.digir.net was identified as  
"216.34.181.97", and the DNS entry for digir.net was updated  
appropriately.  Since the TTL on that DNS record was set relatively  
short (600 seconds), the DNS infrastructure picked up the new  
information fairly quickly, and testing indicates that digir.net URLs  
are now being correctly resolved from several locations around the  
world.


= What You Need To Do =

Nothing.  You should not notice any ongoing disruption.


= Ensuring Continued Operation =

There are three major issues that lead to this malfunction (#2 and #3  
are informational only for developers of new services and tools):

  1. We have no control over Source Forge, and nor should digir.net  
infrastructure be dependent on them

  2. Much of the existing installed DiGIR infrastructure references  
"digir.net" directly and so DNS level indirection is not practical.

  3. HTTP redirects need to be supported in service implementations  
and their clients.  I suspect that a lot of DiGIR software services  
and clients do not follow redirects properly.


== Issue #1 ==

A DNS monitoring service is now in place that will update the DNS  
entries if the source forge machine changes again.

Also, a replica of the DiGIR web material currently hosted by Source  
Forge is being created on a machine that we have complete control over  
and is located on a fast internet backbone.  The replica machine will  
be monitored with a system that will provide automatic notification to  
appropriate contacts in the event of failure.  This machine will be  
located at the University of Kansas at least initially.  Once  
operational, the DNS entry for digir.net will be modified to point to  
this machine.

DNS services are handled by dyndns.org.  Since their inception they  
have provided a 100% uptime for their clients which includes domains  
such as CNN, Mozilla, and Twitter.  Since digir.net was an early  
adopter of their services, the DNS service provided by DynDNS does not  
expire.  DNS registration does expire however, and this relatively  
minor expense is covered by the University of Kansas with assistance  
from the National Science Foundation.


== Issue #2 ==

In retrospect, something like "http://schema.digir.net" rather than "http://digir.net 
" should have been used.  This would have provided a low level (DNS)  
mechanism for indirection that would have been unaffected by this  
unanticipated hardware change.  Altering these entries in DiGIR  
providers and tools is really not practical at this stage, so it is  
unlikely that this issue can be directly addressed.


== Issue #3 ==

HTTP offers a mechanism for temporary and permanent redirection.  In  
order to take advantage of this functionality, it is necessary for  
HTTP clients to properly interpret the HTTP 301 and 307 status codes  
and the respective response headers to determine the new location of  
the resource being resolved.  This is the mechanism employed by PURLs  
and TinyURL for example.  Unfortunately, many developers take short  
cuts when building tools to retrieve content from URLs and avoid the  
additional small amount of work necessary to handle redirect  
messages.  Where ever possible, developers of services and clients  
should use libraries that at least properly handle HTTP redirects  
which will allow the use of PURLs and other mechanisms for providing  
an additional level of indirection in URL resolution where necessary.


regards,
   Dave Vieglais

---
Biodiversity Research Center
University of Kansas

Re: [Digir-dev] digir (php) error

[Döring, M. <m.doering@BGBM.org>]

thanks guys,
so I will recommend to use PHP4 in any case.
markus



-----Original Message-----
From:	dig...@li... on behalf of John R. WIECZOREK
Sent:	Fri 4/4/2008 5:57 PM
To:	Renato De Giovanni
Cc:	dig...@li...
Subject:	Re: [Digir-dev] digir (php) error

Dear all,

There were some problems with early combinations of PHP5, Apache2.2, and the
Pear libraries. As far as I know these are resolved in later versions. I
know for sure that we have many PHP5.x and Apache2.x functioning. I also
know that the PHP4 combination didn't ever have the problem. Still, this
problem Markus is not one I've seen before, but I haven't yet installed a
provider under the same conditions.

John

On Fri, Apr 4, 2008 at 8:29 AM, Renato De Giovanni <re...@cr...>
wrote:

> Hi Markus,
>
> I know there are problems using the DiGIR provider with PHP 5.x versions.
> I can't remember exactly what they were, but I can try to find something
> in my e-mail history if you need. Anyway, my recommendation for DiGIR
> users is simply to use it only with PHP 4.x.
>
> Best Regards,
> --
> Renato
>
>
> > Hi,
> > I have done a fresh install of a PHP DiGIR 1.21 provider on Mac OSX
> > 10.5 [PHP 5.2.5,Apache 2.2.8].
> > It seemed to work fine until I added a new (and first) resource in the
> > web configuration. After a second I got an error and the Apache logs
> > tell me this:
> > "child pid 10256 exit signal Segmentation fault (11)"
> >
> > Looks like PHP died. Anyone experienced any problems like that before?
> > I have tried it with the latest MAMP release too and got the same
> > error (also using PHP 5.2.5).
> >
> > thanks,
> > Markus
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> DiGIR-developers mailing list
> DiG...@li...
> https://lists.sourceforge.net/lists/listinfo/digir-developers
>

Re: [Digir-dev] digir (php) error

[John R. W. <tu...@be...>]

Dear all,

There were some problems with early combinations of PHP5, Apache2.2, and the
Pear libraries. As far as I know these are resolved in later versions. I
know for sure that we have many PHP5.x and Apache2.x functioning. I also
know that the PHP4 combination didn't ever have the problem. Still, this
problem Markus is not one I've seen before, but I haven't yet installed a
provider under the same conditions.

John

On Fri, Apr 4, 2008 at 8:29 AM, Renato De Giovanni <re...@cr...>
wrote:

> Hi Markus,
>
> I know there are problems using the DiGIR provider with PHP 5.x versions.
> I can't remember exactly what they were, but I can try to find something
> in my e-mail history if you need. Anyway, my recommendation for DiGIR
> users is simply to use it only with PHP 4.x.
>
> Best Regards,
> --
> Renato
>
>
> > Hi,
> > I have done a fresh install of a PHP DiGIR 1.21 provider on Mac OSX
> > 10.5 [PHP 5.2.5,Apache 2.2.8].
> > It seemed to work fine until I added a new (and first) resource in the
> > web configuration. After a second I got an error and the Apache logs
> > tell me this:
> > "child pid 10256 exit signal Segmentation fault (11)"
> >
> > Looks like PHP died. Anyone experienced any problems like that before?
> > I have tried it with the latest MAMP release too and got the same
> > error (also using PHP 5.2.5).
> >
> > thanks,
> > Markus
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> DiGIR-developers mailing list
> DiG...@li...
> https://lists.sourceforge.net/lists/listinfo/digir-developers
>

Re: [Digir-dev] digir (php) error

[Renato De G. <re...@cr...>]

Hi Markus,

I know there are problems using the DiGIR provider with PHP 5.x versions.
I can't remember exactly what they were, but I can try to find something
in my e-mail history if you need. Anyway, my recommendation for DiGIR
users is simply to use it only with PHP 4.x.

Best Regards,
--
Renato


> Hi,
> I have done a fresh install of a PHP DiGIR 1.21 provider on Mac OSX
> 10.5 [PHP 5.2.5,Apache 2.2.8].
> It seemed to work fine until I added a new (and first) resource in the
> web configuration. After a second I got an error and the Apache logs
> tell me this:
> "child pid 10256 exit signal Segmentation fault (11)"
>
> Looks like PHP died. Anyone experienced any problems like that before?
> I have tried it with the latest MAMP release too and got the same
> error (also using PHP 5.2.5).
>
> thanks,
> Markus

[Digir-dev] digir (php) error

[Markus D. <mdo...@gb...>]

Hi,
I have done a fresh install of a PHP DiGIR 1.21 provider on Mac OSX  
10.5 [PHP 5.2.5,Apache 2.2.8].
It seemed to work fine until I added a new (and first) resource in the  
web configuration. After a second I got an error and the Apache logs  
tell me this:
"child pid 10256 exit signal Segmentation fault (11)"

Looks like PHP died. Anyone experienced any problems like that before?
I have tried it with the latest MAMP release too and got the same  
error (also using PHP 5.2.5).

thanks,
Markus

Re: [Digir-dev] Configuring DiGIR issue

[Renato De G. <re...@cr...>]

John,

You can probably just manually copy the following file to your "config"
directory:

http://digir.net/schema/protocol/2003/1.0/digir.xsd

Hope this helps,
--
Renato

> Hi,
>
> I'm hoping for a bit of advice, on a DiGIR installation issue.
>
> We are trying to migrate our DiGIR system across to a new server
> infrastructure.  Under the new system, DiGIR needs to be routed via a
> proxy server when it wishes to contact the outside world (specifically to
> pick up the XSD file).  I'm not sure how to get DiGIR to do that, so I was
> hoping you might have some suggestions as to how I proceed.
>
> Cheers,
> John

[Digir-dev] Configuring DiGIR issue

[John W. <j....@ke...>]

Hi,

I'm hoping for a bit of advice, on a DiGIR installation issue.

We are trying to migrate our DiGIR system across to a new server infrastruc=
ture.  Under the new system, DiGIR needs to be routed via a proxy server wh=
en it wishes to contact the outside world (specifically to pick up the XSD =
file).  I'm not sure how to get DiGIR to do that, so I was hoping you might=
 have some suggestions as to how I proceed.

Cheers,
John

Re: [Digir-dev] search result page

[Renato De G. <re...@cr...>]

Fred,

To avoid that warning, you should either map the "julian day" concept in
your provider configuration or remove the same concept from the response
strucure at
http://akn.ornith.cornell.edu/Schemas/bmde/BMDEv1.0_fullresults.xsd

Hope this helps,
--
Renato

> Hello all, I was hoping to find a way to suppress the diagnostics codes so
> that they do not appear on the xml result page. Please follow this link:
> http://akn.klamathbird.org/digir/test/fg_search.php and click the Submit
> Request button to see what I mean, at the bottom of the results page you
> will see what I am trying to suppress.
>
> Thank you,
>
> Fred Graves
> USDA Forest Service
> Redwood Sciences Lab - Arcata, CA
> (707) 825-2948 - fg...@fs...

[Digir-dev] search result page

[Fred G. <fg...@fs...>]

Hello all, I was hoping to find a way to suppress the diagnostics codes so
that they do not appear on the xml result page. Please follow this link:
http://akn.klamathbird.org/digir/test/fg_search.php and click the Submit
Request button to see what I mean, at the bottom of the results page you
will see what I am trying to suppress.

Thank you,

Fred Graves
USDA Forest Service
Redwood Sciences Lab - Arcata, CA
(707) 825-2948 - fg...@fs...

[Digir-dev] digir Developers, when's your birthday?

[Siva P. N. G. <al...@bi...>]

digir  Developers,

Click on the link to enter your birthday so I won't forget it:
http://www.birthdaytime.com/addyourbday.php?id=GFcIKLDv%2BZPHD1eMHRLV%2F2Np0sKeVMn%2BIZO6JMkocKj601X4RznJoL8XNioFR%2B7KdbG18h6y9Pc%3D&data=KPrfaUlwVK4s5VuMHsLahk62sgSJGV9XJMgtAI4f5zrfJEIHQTUwvniiTZqp6KpbGweO20A0D0hni9mvtrubOQ%3D%3D

Thanks!

Siva Prashaatharan Nair Giggsy, (rut...@ya...)

Birthdaytime.com
Never forget to say Happy Birthday to the ones you love






-----------------------------------------------------------
This email was sent by Siva Prashaatharan Nair Giggsy (rut...@ya...).If you do not wish to receive future mailings from birthdaytime, please click on the link below. BirthdayTime's offices are located at 2202 S. Figueroa St, Los angeles, CA 90007.

http://www.birthdaytime.com/cancelfollow.php?id=GFcIKLDv%2BZPHD1eMHRLV%2F2Np0sKeVMn%2BIZO6JMkocKj601X4RznJoL8XNioFR%2B7KdbG18h6y9Pc%3D&data=KPrfaUlwVK4s5VuMHsLahk62sgSJGV9XJMgtAI4f5zrfJEIHQTUwvniiTZqp6KpbGweO20A0D0hni9mvtrubOQ%3D%3D

[Digir-dev] Pls add your birthday to my calendar...

[Siva P. N. G. <al...@bi...>]

I'm building a birthday calendar and I would really appreciate if you could help me out.

Simply click on the link below and enter your birthday into my calendar:

http://www.birthdaytime.com/addyourbday.php?id=GFcIKLDv%2BZPHD1eMHRLV%2F2Np0sKeVMn%2BIZO6JMkocKj601X4RznJoL8XNioFR%2B7KdbG18h6y9Pc%3D&data=KPrfaUlwVK4s5VuMHsLahk62sgSJGV9XJMgtAI4f5zrfJEIHQTUwvniiTZqp6KpbGweO20A0D0hni9mvtrubOQ%3D%3D>
                                                      .
It is simple, fast and you will help me to remember it!

Thanks!

Siva Prashaatharan Nair Giggsy






-----------------------------------------------------------
This email was sent by Siva Prashaatharan Nair Giggsy (rut...@ya...).If you do not wish to receive future mailings from birthdaytime, please click on the link below. BirthdayTime's offices are located at 2202 S. Figueroa St, Los angeles, CA 90007.

http://www.birthdaytime.com/cancelfollow.php?id=GFcIKLDv%2BZPHD1eMHRLV%2F2Np0sKeVMn%2BIZO6JMkocKj601X4RznJoL8XNioFR%2B7KdbG18h6y9Pc%3D&data=KPrfaUlwVK4s5VuMHsLahk62sgSJGV9XJMgtAI4f5zrfJEIHQTUwvniiTZqp6KpbGweO20A0D0hni9mvtrubOQ%3D%3D

Re: [Digir-dev] Digir provider connections issue

[John W. <j....@rb...>]

Hi,

I was happy to make the suggested change, which hopefully should solve future 
caching issues.  I suspect that it won't solve the threading issue though.  Hopefully 
the new version of DiGIR will have an option to control the maximum number of 
connections DiGIR can have running?

Cheers,
John

> I don't know if this is the solution you need, but I would like to know if
> you are willing to try it, or at least have a look to see if this is the
> case. There were known problems with caching (though I don't know the exact
> nature of the problem personally) using the DiGIR provider, so we turned it
> off in any existing installations. Can you check to see if you have caching
> turned on? It is set by the line in localConfig.php that may be commented
> out. I set it like this to turn caching off:
> 
> define('DIGIR_USE_CACHE', FALSE);
> 
> We are hoping to have a new DIGIR provider release within a week - one that
> has log querying capabilities. Some of the capabilities are there in CVS,
> but there will be a number of changes committed as soon as I have a chance
> to test them to a reasonable extent. Once committed, I will create a new
> downloadable release on http://sourceforge.net/projects/digir - the first
> one since 2003!
> 
> On 9/26/06, John Wall <j....@rb...> wrote:
> >
> >  Hi,
> >
> > A few months ago, we installed the DiGIR provider to provide data to the
> > GBIF portal.  It ran with some teething troubles relating to cache size
> > until last week we had our first big hit on the provider, which caused a
> > massive increase in connections to the mysql database we are using to hold
> > the content.  We then discovered that the DiGIR provider was not releasing
> > connections (which in turn was causing other systems to fail). As a short
> > term measure, we then restricted the maximum number of connections mysql
> > would permit the user to have. This prevents DiGIR from overwelming mysql
> > but now DiGIR has used up the connections and will not query the database,
> > presumably because the connections are being held and are not available.
> >
> > Looking at the documentation I can't see where the maximum number of
> > connections is set (of course, I might be looking in the wrong place!).  I'm
> > not a php person so looking at the code isn't helping.  I've also tried to
> > download the latest cvs snapshot from www.digir.net but every time we try
> > it we get a corrupted file warning (tried this on 2 difference machines at
> > work).
> >
> > Heres the diagnostics we get from DiGIR.php:
> >
> > <diagnostics>
> >
> > <diagnostic code="*STATUS_INTERVAL*" severity="*info*">600</diagnostic>
> >
> > <diagnostic code="*STATUS_DATA*" severity="*info*">2,0,0</diagnostic>
> >
> > <diagnostic code="*Unknown PHP Error [2]*" severity="*DIAG_WARNING*">mysql_pconnect():
> > User 'digir' has exceeded the 'max_connections' resource (current value: 10)
> > (/home/www/docs/digir/lib/adodb/drivers/adodb- mysql.inc.php:251)</diagnostic>
> >
> >
> > <diagnostic code="*INTERNAL_DATABASE_ERROR*" severity="*error*">ADOdb
> > reported error connecting to database:User 'digir' has exceeded the
> > 'max_connections' resource (current value: 10)</diagnostic>
> >
> > <diagnostic code="*Unknown PHP Error [2]*" severity="*DIAG_WARNING*">mysql_close():
> > supplied argument is not a valid MySQL-Link resource
> > (/home/www/docs/digir/lib/adodb/drivers/adodb- mysql.inc.php:370)</diagnostic>
> >
> >
> > </diagnostics>
> >
> >
> >  I hope you can help!
> >
> > John Wall
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your
> > opinions on IT & business topics through brief surveys -- and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >
> > _______________________________________________
> > DiGIR-developers mailing list
> > DiG...@li...
> > https://lists.sourceforge.net/lists/listinfo/digir-developers
> >
> >
> >
> 

Re: [Digir-dev] Digir provider connections issue

[John R. W. <tu...@be...>]

I don't know if this is the solution you need, but I would like to know if
you are willing to try it, or at least have a look to see if this is the
case. There were known problems with caching (though I don't know the exact
nature of the problem personally) using the DiGIR provider, so we turned it
off in any existing installations. Can you check to see if you have caching
turned on? It is set by the line in localConfig.php that may be commented
out. I set it like this to turn caching off:

define('DIGIR_USE_CACHE', FALSE);

We are hoping to have a new DIGIR provider release within a week - one that
has log querying capabilities. Some of the capabilities are there in CVS,
but there will be a number of changes committed as soon as I have a chance
to test them to a reasonable extent. Once committed, I will create a new
downloadable release on http://sourceforge.net/projects/digir - the first
one since 2003!

On 9/26/06, John Wall <j....@rb...> wrote:
>
>  Hi,
>
> A few months ago, we installed the DiGIR provider to provide data to the
> GBIF portal.  It ran with some teething troubles relating to cache size
> until last week we had our first big hit on the provider, which caused a
> massive increase in connections to the mysql database we are using to hold
> the content.  We then discovered that the DiGIR provider was not releasing
> connections (which in turn was causing other systems to fail). As a short
> term measure, we then restricted the maximum number of connections mysql
> would permit the user to have. This prevents DiGIR from overwelming mysql
> but now DiGIR has used up the connections and will not query the database,
> presumably because the connections are being held and are not available.
>
> Looking at the documentation I can't see where the maximum number of
> connections is set (of course, I might be looking in the wrong place!).  I'm
> not a php person so looking at the code isn't helping.  I've also tried to
> download the latest cvs snapshot from www.digir.net but every time we try
> it we get a corrupted file warning (tried this on 2 difference machines at
> work).
>
> Heres the diagnostics we get from DiGIR.php:
>
> <diagnostics>
>
> <diagnostic code="*STATUS_INTERVAL*" severity="*info*">600</diagnostic>
>
> <diagnostic code="*STATUS_DATA*" severity="*info*">2,0,0</diagnostic>
>
> <diagnostic code="*Unknown PHP Error [2]*" severity="*DIAG_WARNING*">mysql_pconnect():
> User 'digir' has exceeded the 'max_connections' resource (current value: 10)
> (/home/www/docs/digir/lib/adodb/drivers/adodb- mysql.inc.php:251)</diagnostic>
>
>
> <diagnostic code="*INTERNAL_DATABASE_ERROR*" severity="*error*">ADOdb
> reported error connecting to database:User 'digir' has exceeded the
> 'max_connections' resource (current value: 10)</diagnostic>
>
> <diagnostic code="*Unknown PHP Error [2]*" severity="*DIAG_WARNING*">mysql_close():
> supplied argument is not a valid MySQL-Link resource
> (/home/www/docs/digir/lib/adodb/drivers/adodb- mysql.inc.php:370)</diagnostic>
>
>
> </diagnostics>
>
>
>  I hope you can help!
>
> John Wall
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> _______________________________________________
> DiGIR-developers mailing list
> DiG...@li...
> https://lists.sourceforge.net/lists/listinfo/digir-developers
>
>
>

[Digir-dev] Digir provider connections issue

[John W. <j....@rb...>]

<?xml  version="1.0" ?><html>
<head>
<title></title>
</head>
<body>
<p><font face="Times New Roman" size="3"><span style="font-size:12pt">Hi,</span></font></p>
<p><font face="Times New Roman" size="3"><span style="font-size:12pt">A few months ago, we installed the DiGIR provider to provide 
data to the GBIF portal.&#160; It ran with some teething troubles 
relating to cache size until last week we had our first big hit on 
the provider, which caused a massive increase in connections 
to the mysql database we are using to hold the content.&#160; We 
then discovered that the DiGIR provider was not releasing 
connections (which in turn was causing other systems to fail). 
As a short term measure, we then restricted the maximum 
number of connections mysql would permit the user to have. 
This prevents DiGIR from overwelming mysql but now DiGIR 
has used up the connections and will not query the database, 
presumably because the connections are being held and are not 
available.</span></font></p>
<p><font face="Times New Roman" size="3"><span style="font-size:12pt">Looking at the documentation I can't see where the maximum 
number of connections is set (of course, I might be looking in 
the wrong place!).&#160; I'm not a php person so looking at the code 
isn't helping.&#160; I've also tried to download the latest cvs 
snapshot from www.digir.net but every time we try it we get a 
corrupted file warning (tried this on 2 difference machines at 
work).</span></font></p>
<p><font face="Times New Roman" size="3"><span style="font-size:12pt">Heres the diagnostics we get from DiGIR.php:</span></font></p>
<p><font face="Times New Roman" size="3"><span style="font-size:12pt">&lt;diagnostics&gt; </span></font></p>
<p><font face="Times New Roman" size="3"><span style="font-size:12pt">&lt;diagnostic code=&quot;<b>STATUS_INTERVAL</b>&quot; 
severity=&quot;<b>info</b>&quot;&gt;600&lt;/diagnostic&gt; </span></font></p>
<p><font face="Times New Roman" size="3"><span style="font-size:12pt">&lt;diagnostic code=&quot;<b>STATUS_DATA</b>&quot; 
severity=&quot;<b>info</b>&quot;&gt;2,0,0&lt;/diagnostic&gt; </span></font></p>
<p><font face="Times New Roman" size="3"><span style="font-size:12pt">&lt;diagnostic code=&quot;<b>Unknown PHP Error [2]</b>&quot; 
severity=&quot;<b>DIAG_WARNING</b>&quot;&gt;mysql_pconnect(): User 'digir' 
has exceeded the 'max_connections' resource (current value: 
10) (/home/www/docs/digir/lib/adodb/drivers/adodb-
mysql.inc.php:251)&lt;/diagnostic&gt; </span></font></p>
<p><font face="Times New Roman" size="3"><span style="font-size:12pt">&lt;diagnostic code=&quot;<b>INTERNAL_DATABASE_ERROR</b>&quot; 
severity=&quot;<b>error</b>&quot;&gt;ADOdb reported error connecting to 
database:User 'digir' has exceeded the 'max_connections' 
resource (current value: 10)&lt;/diagnostic&gt; </span></font></p>
<p><font face="Times New Roman" size="3"><span style="font-size:12pt">&lt;diagnostic code=&quot;<b>Unknown PHP Error [2]</b>&quot; 
severity=&quot;<b>DIAG_WARNING</b>&quot;&gt;mysql_close(): supplied 
argument is not a valid MySQL-Link resource 
(/home/www/docs/digir/lib/adodb/drivers/adodb-
mysql.inc.php:370)&lt;/diagnostic&gt; </span></font></p>
<p><font face="Times New Roman" size="3"><span style="font-size:12pt">&lt;/diagnostics&gt;</span></font></p>
<p><br/>
</p>
<p><font face="Times New Roman" size="3"><span style="font-size:12pt">I hope you can help!</span></font></p>
<p><font face="Times New Roman" size="3"><span style="font-size:12pt">John Wall</span></font></p>
<div align="left"></div>
</body>
</html>

Re: [Digir-dev] DiGIR and MS_Access

[Kevin W. <kf...@co...>]

Thanks for your reply Dave.

I wasn't able to execute the SQL because the data-source is
at a remote site. Your suggestion, however, was the genesis
for solving this issue by hinting that it might be a configuration
issue. Through trial-and-error I discovered that I needed to add
a name for the database in the 'Datasource' configuration
screen for this resource. Whereas it appears that DiGIR
inventory requests work without a database name, DiGIR
searches depend on one.

Thank you all for your time and consideration.

KFW


At 04:12 PM 3/27/2006, Dave Vieglais wrote:
>Hi Kevin,
>Does the SQL statement in the diagnostic execute as expected from within 
>Access?
>
>Dave V.
>
>Kevin Webb said the following on 03/28/2006 08:19 AM:
>>Greetings!
>>I have an issue when searching a DiGIR resource that uses MS-Access
>>as the data source. Inventory requests work correctly and result in 
>>well-formed
>>responses, search requests on the other hand generate the following error
>>statement.
>>
>><diagnostic code="STATUS_INTERVAL" severity="info">600</diagnostic>
>><diagnostic code="STATUS_DATA" severity="info">0,20,1</diagnostic>
>><diagnostic code="Unknown PHP Error [2]" 
>>severity="DIAG_WARNING">(null)(): Invoke() failed: Exception occurred.
>>  &lt;b&gt;Source&lt;/b&gt;: Unavailable &lt;b&gt;Description&lt;/b&gt;: 
>> Unavailable 
>> (F:\root\DiGIRprov\lib\adodb\drivers\adodb-ado.inc.php:227)</diagnostic>
>><diagnostic code="QUERY_PRODUCED_NO_RESULTS" severity="warn">The query 
>>generated a null resultset.</diagnostic>
>><diagnostic code="DATABASE_ERROR" severity="error"></diagnostic>
>><diagnostic code="SQL_DEBUG_INFO" severity="debug">SELECT 
>>pointsurvey.birdid, pointsurvey.state, pointsurvey.county, 
>>pointsurvey.year, pointsurvey.initials, pointsurvey.sex, 
>>pointsurvey.transect_transectid, pointsurvey.pointvisitid, 
>>pointsurvey.transectnum, pointsurvey.starttime, pointsurvey.endtime, 
>>pointsurvey.perpenddistance,radialdistance, pointsurvey.bearingtobird, 
>>pointsurvey.count, pointsurvey.date, pointsurvey.zone, 
>>pointsurvey.northing, pointsurvey.easting FROM pointsurvey WHERE 
>>((pointsurvey.state = 'WY'))</diagnostic>
>>I have 3 questions regarding this error statement.
>>1. Why would a search request on a concept that has been reported as having
>>a non-null data set via an inventory request report a null result set 
>>when searched?
>>This is the inventory response associated with the previous search 
>>request error.
>><record>
>>   <bmde:StateProvince count="*111939*">WY</bmde:StateProvince>
>>  </record>
>>2. Why would the call to Execute() at line 227 of  adodb-ado.inc.php
>>report an availability issue when inventory requests execute to completion?
>>3. What should I do to correct this?
>>
>>Thank you.
>>
>>KFW
>>
>>-----------------------------------------
>>Kevin Webb
>>Programmer/Analyst
>>Cornell Lab of Ornithology
>>159 Sapsucker Woods Rd.
>>Ithaca, NY 14850
>>Tel: 607.254.2103
>>Fax: 607.254.2415
>>kf...@co...
>>-------------------------------------------
>
>

-----------------------------------------
Kevin Webb
Programmer/Analyst
Cornell Lab of Ornithology
159 Sapsucker Woods Rd.
Ithaca, NY 14850
Tel: 607.254.2103
Fax: 607.254.2415
kf...@co...
-------------------------------------------

Re: [Digir-dev] DiGIR and MS_Access

[Dave V. <vie...@ku...>]

Hi Kevin,
Does the SQL statement in the diagnostic execute as expected from within Access?

Dave V.

Kevin Webb said the following on 03/28/2006 08:19 AM:
> Greetings!
> 
> I have an issue when searching a DiGIR resource that uses MS-Access
> as the data source. Inventory requests work correctly and result in 
> well-formed
> responses, search requests on the other hand generate the following error
> statement.
> 
> 
> <diagnostic code="STATUS_INTERVAL" severity="info">600</diagnostic>
> <diagnostic code="STATUS_DATA" severity="info">0,20,1</diagnostic>
> <diagnostic code="Unknown PHP Error [2]" 
> severity="DIAG_WARNING">(null)(): Invoke() failed: Exception occurred.
>  &lt;b&gt;Source&lt;/b&gt;: Unavailable &lt;b&gt;Description&lt;/b&gt;: 
> Unavailable 
> (F:\root\DiGIRprov\lib\adodb\drivers\adodb-ado.inc.php:227)</diagnostic>
> <diagnostic code="QUERY_PRODUCED_NO_RESULTS" severity="warn">The query 
> generated a null resultset.</diagnostic>
> <diagnostic code="DATABASE_ERROR" severity="error"></diagnostic>
> <diagnostic code="SQL_DEBUG_INFO" severity="debug">SELECT 
> pointsurvey.birdid, pointsurvey.state, pointsurvey.county, 
> pointsurvey.year, pointsurvey.initials, pointsurvey.sex, 
> pointsurvey.transect_transectid, pointsurvey.pointvisitid, 
> pointsurvey.transectnum, pointsurvey.starttime, pointsurvey.endtime, 
> pointsurvey.perpenddistance,radialdistance, pointsurvey.bearingtobird, 
> pointsurvey.count, pointsurvey.date, pointsurvey.zone, 
> pointsurvey.northing, pointsurvey.easting FROM pointsurvey WHERE 
> ((pointsurvey.state = 'WY'))</diagnostic>
> 
> I have 3 questions regarding this error statement.
> 
> 1. Why would a search request on a concept that has been reported as having
> a non-null data set via an inventory request report a null result set 
> when searched?
> 
> This is the inventory response associated with the previous search 
> request error.
> 
> <record>
>   <bmde:StateProvince count="*111939*">WY</bmde:StateProvince>
>  </record>
> 
> 2. Why would the call to Execute() at line 227 of  adodb-ado.inc.php
> report an availability issue when inventory requests execute to completion?
> 
> 3. What should I do to correct this?
> 
> 
> 
> Thank you.
> 
> 
> KFW
> 
> 
> 
> -----------------------------------------
> Kevin Webb
> Programmer/Analyst
> Cornell Lab of Ornithology
> 159 Sapsucker Woods Rd.
> Ithaca, NY 14850
> Tel: 607.254.2103
> Fax: 607.254.2415
> kf...@co...
> -------------------------------------------
> 

RE: [Digir-dev] DiGIR and MS_Access

[Kevin W. <kf...@co...>]

Hi Donald,
Thank you for a very speedy reply.

MinQueryTermLength is set = 2. I had been setting this value to 3 but
noticed that John Wieczorek was using 2 for his configurations, and I
have been using 2 since.

Thanks again.


KFW



At 03:33 PM 3/27/2006, Donald Hobern wrote:
>Dear Kevin,
>
>Check the configuration for the resource.  What is the setting for 
>minQueryTermLength?  I expect it is 3.  This was a bug that was reported 
>and fixed in the source but I think has not made it into the standard 
>installations.  It only makes sense to check the length when using <like>, 
>not for <equals>.  Try changing this value to 2 and see what happens.
>
>Best wishes,
>
>Donald
>
>---------------------------------------------------------------
>Donald Hobern (<mailto:dh...@gb...>dh...@gb...)
>Programme Officer for Data Access and Database Interoperability
>Global Biodiversity Information Facility Secretariat
>Universitetsparken 15, DK-2100 Copenhagen, Denmark
>Tel: +45-35321483   Mobile: +45-28751483   Fax: +45-35321480
>---------------------------------------------------------------
>
>----------
>From: dig...@li... 
>[mailto:dig...@li...] On Behalf Of Kevin Webb
>Sent: 27 March 2006 22:19
>To: dig...@li...
>Subject: [Digir-dev] DiGIR and MS_Access
>
>Greetings!
>
>I have an issue when searching a DiGIR resource that uses MS-Access
>as the data source. Inventory requests work correctly and result in 
>well-formed
>responses, search requests on the other hand generate the following error
>statement.
>
>
><diagnostic code="STATUS_INTERVAL" severity="info">600</diagnostic>
><diagnostic code="STATUS_DATA" severity="info">0,20,1</diagnostic>
><diagnostic code="Unknown PHP Error [2]" severity="DIAG_WARNING">(null)(): 
>Invoke() failed: Exception occurred.
>  &lt;b&gt;Source&lt;/b&gt;: Unavailable &lt;b&gt;Description&lt;/b&gt;: 
> Unavailable 
> (F:\root\DiGIRprov\lib\adodb\drivers\adodb-ado.inc.php:227)</diagnostic>
><diagnostic code="QUERY_PRODUCED_NO_RESULTS" severity="warn">The query 
>generated a null resultset.</diagnostic>
><diagnostic code="DATABASE_ERROR" severity="error"></diagnostic>
><diagnostic code="SQL_DEBUG_INFO" severity="debug">SELECT 
>pointsurvey.birdid, pointsurvey.state, pointsurvey.county, 
>pointsurvey.year, pointsurvey.initials, pointsurvey.sex, 
>pointsurvey.transect_transectid, pointsurvey.pointvisitid, 
>pointsurvey.transectnum, pointsurvey.starttime, pointsurvey.endtime, 
>pointsurvey.perpenddistance,radialdistance, pointsurvey.bearingtobird, 
>pointsurvey.count, pointsurvey.date, pointsurvey.zone, 
>pointsurvey.northing, pointsurvey.easting FROM pointsurvey WHERE 
>((pointsurvey.state = 'WY'))</diagnostic>
>
>I have 3 questions regarding this error statement.
>
>1. Why would a search request on a concept that has been reported as having
>a non-null data set via an inventory request report a null result set when 
>searched?
>
>This is the inventory response associated with the previous search request 
>error.
>
><record>
>   <bmde:StateProvince count="111939">WY</bmde:StateProvince>
>  </record>
>
>2. Why would the call to Execute() at line 227 of  adodb-ado.inc.php
>report an availability issue when inventory requests execute to completion?
>
>3. What should I do to correct this?
>
>
>
>Thank you.
>
>
>KFW
>
>
>
>
>-----------------------------------------
>Kevin Webb
>Programmer/Analyst
>Cornell Lab of Ornithology
>159 Sapsucker Woods Rd.
>Ithaca, NY 14850
>Tel: 607.254.2103
>Fax: 607.254.2415
>kf...@co...
>-------------------------------------------

-----------------------------------------
Kevin Webb
Programmer/Analyst
Cornell Lab of Ornithology
159 Sapsucker Woods Rd.
Ithaca, NY 14850
Tel: 607.254.2103
Fax: 607.254.2415
kf...@co...
-------------------------------------------