From christian.zimmermann at uconn.edu  Mon Feb  9 08:35:12 2009
From: christian.zimmermann at uconn.edu (Christian Zimmermann)
Date: Mon, 9 Feb 2009 08:35:12 -0500 (EST)
Subject: [RAS] Invalid page address (fwd)
Message-ID: <Pine.LNX.4.64.0902090832590.3066@fondue.econ.uconn.edu>

It looks like after all, we have a problem with short-IDs above 1000. See 
below. The web version of the profile on RAS was not created, and this 
seems to be the case with others like pma10??. The rest of the new 
profiles are fine.

Christian Zimmermann                                     FIGUGEGL!
Department of Economics
University of Connecticut
341 Mansfield Road, Unit 1063
Storrs, CT 06269-1063
http://ideas.repec.org/zimm/   christian.zimmermann at uconn.edu
http://ideas.repec.org/e/pzi1.html

---------- Forwarded message ----------
Date: Mon, 09 Feb 2009 08:51:55 +0100
From: Jaime Martinez-Martin <jaime.martinezmartin at ub.edu>
Reply-To: Jaime at baron.mgmt.ad.uconn.edu, Martinez-Martin at baron.mgmt.ad.uconn.edu
To: authors at repec.org
Subject: Invalid page address

Hi,

my name is Jaime Martinez-Martin and I've been experiencing some problems to
register as an author at Repec-Ideas. I have no publications yet but I was
trying to register as soon as possible since I will publish a couple of working
papers very soon.

http://authors.repec.org/pro/pma1013/


Thanks in advanced for your attention,

-- 
Jaime Martinez-Martin
AQR Research Group
University of Barcelona
Avda Diagonal 690, 08034 Barcelona (Spain)

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/


From duraley at gmail.com  Mon Feb  9 09:58:47 2009
From: duraley at gmail.com (Ivan Kurmanov)
Date: Mon, 9 Feb 2009 16:58:47 +0200
Subject: [RAS] Invalid page address (fwd)
In-Reply-To: <Pine.LNX.4.64.0902090832590.3066@fondue.econ.uconn.edu>
References: <Pine.LNX.4.64.0902090832590.3066@fondue.econ.uconn.edu>
Message-ID: <f46ffd910902090658p5d06b5d8m7aa0dd8b095a7163@mail.gmail.com>

If I get it right, it is an issue of the apache configuration.

We need to add something like the following to it:

RewriteRule ^/P/(.)(.)(.)(.)(.)(.)/(.*) /profile/p/$1/$2/$3/$4/$5/$6/$7 [L]

Thomas, could you please allow duraley at gmail.com to post to RAS-RUN list?

-ivan

On Mon, Feb 9, 2009 at 3:35 PM, Christian Zimmermann
<christian.zimmermann at uconn.edu> wrote:
> It looks like after all, we have a problem with short-IDs above 1000. See
> below. The web version of the profile on RAS was not created, and this seems
> to be the case with others like pma10??. The rest of the new profiles are
> fine.
>
> Christian Zimmermann                                     FIGUGEGL!
> Department of Economics
> University of Connecticut
> 341 Mansfield Road, Unit 1063
> Storrs, CT 06269-1063
> http://ideas.repec.org/zimm/   christian.zimmermann at uconn.edu
> http://ideas.repec.org/e/pzi1.html
>
> ---------- Forwarded message ----------
> Date: Mon, 09 Feb 2009 08:51:55 +0100
> From: Jaime Martinez-Martin <jaime.martinezmartin at ub.edu>
> Reply-To: Jaime at baron.mgmt.ad.uconn.edu,
> Martinez-Martin at baron.mgmt.ad.uconn.edu
> To: authors at repec.org
> Subject: Invalid page address
>
> Hi,
>
> my name is Jaime Martinez-Martin and I've been experiencing some problems to
> register as an author at Repec-Ideas. I have no publications yet but I was
> trying to register as soon as possible since I will publish a couple of
> working
> papers very soon.
>
> http://authors.repec.org/pro/pma1013/
>
>
> Thanks in advanced for your attention,
>
> --
> Jaime Martinez-Martin
> AQR Research Group
> University of Barcelona
> Avda Diagonal 690, 08034 Barcelona (Spain)
>
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
>


From krichel at openlib.org  Mon Feb  9 17:09:27 2009
From: krichel at openlib.org (Thomas Krichel)
Date: Mon, 9 Feb 2009 16:09:27 -0600
Subject: [RAS] Invalid page address (fwd)
In-Reply-To: <f46ffd910902090658p5d06b5d8m7aa0dd8b095a7163@mail.gmail.com>
References: <Pine.LNX.4.64.0902090832590.3066@fondue.econ.uconn.edu>
	<f46ffd910902090658p5d06b5d8m7aa0dd8b095a7163@mail.gmail.com>
Message-ID: <20090209220927.GA16190@openlib.org>

  Ivan Kurmanov writes
> If I get it right, it is an issue of the apache configuration.
> 
> We need to add something like the following to it:
> 
> RewriteRule ^/P/(.)(.)(.)(.)(.)(.)/(.*) /profile/p/$1/$2/$3/$4/$5/$6/$7 [L]


  Added.
> 
> Thomas, could you please allow duraley at gmail.com to post to RAS-RUN list?

Error subscribing:

    * duraley at gmail.com -- Already a member 

  you did it yourself?

  Thanks and cheers,


  Thomas Krichel                    http://openlib.org/home/krichel
                                RePEc:per:1965-06-05:thomas_krichel
                                               skype: thomaskrichel


From krichel at openlib.org  Tue Feb 10 05:40:03 2009
From: krichel at openlib.org (Thomas Krichel)
Date: Tue, 10 Feb 2009 04:40:03 -0600
Subject: [RAS] Invalid page address (fwd)
In-Reply-To: <f46ffd910902090658p5d06b5d8m7aa0dd8b095a7163@mail.gmail.com>
References: <Pine.LNX.4.64.0902090832590.3066@fondue.econ.uconn.edu>
	<f46ffd910902090658p5d06b5d8m7aa0dd8b095a7163@mail.gmail.com>
Message-ID: <20090210104003.GA19106@openlib.org>

  Ivan Kurmanov writes

> 
> RewriteRule ^/P/(.)(.)(.)(.)(.)(.)/(.*) /profile/p/$1/$2/$3/$4/$5/$6/$7 [L]
> 

  I checked again, it should be 
  
  RewriteRule ^/P/(.)(.)(.)(.)(.)(.)/(.*) /pro/p/$1/$2/$3/$4/$5/$6/$7 [L]
 
  It appears to be working properly now.


  Cheers,

  Thomas Krichel                    http://openlib.org/home/krichel
                                RePEc:per:1965-06-05:thomas_krichel
                                               skype: thomaskrichel


From christian.zimmermann at uconn.edu  Tue Feb 10 15:28:46 2009
From: christian.zimmermann at uconn.edu (Christian Zimmermann)
Date: Tue, 10 Feb 2009 15:28:46 -0500 (EST)
Subject: [RAS] [RePEc] Your monthly statistics (fwd)
Message-ID: <Pine.LNX.4.64.0902101526260.3066@fondue.econ.uconn.edu>

This is not the first time this happens: accepted papers get dropped from 
profiles for no apparent reason and attempts to put them back in fail. It 
is only when I do a updareq that items are available again for claiming. 
This has already happened several times for the AER.

This time, it was RePEc:unu:wpaper

Christian Zimmermann                                     FIGUGEGL!
Department of Economics
University of Connecticut
341 Mansfield Road, Unit 1063
Storrs, CT 06269-1063
http://ideas.repec.org/zimm/   christian.zimmermann at uconn.edu
http://ideas.repec.org/e/pzi1.html

---------- Forwarded message ----------
Date: Tue, 10 Feb 2009 08:51:40 +0200
From: ashimeles at worldbank.org
To: Christian Zimmermann <christian.zimmermann at uconn.edu>
Subject: Re: [RePEc] Your monthly statistics


         Dear Prof Zimmerman!
Thanks for the great service you are providing. I just wonder that one working
paper of mine has "disappeared" from my profile, though it had been posted some
time back. I still see the paper at RePEc but does not appear in my profile. The
title of the paper is:

"Finance and poverty in Ethiopia: household level analysis" with (Geda, A &
Zerfu, D) provided by WIDER. Any ideas why?? I could not also add it to my
profile through manual serach!

Best regards

Abebe Shimeles Abebe
Africa Region-PREM
World Bank
P.O.Box 609
Kigali
Rwanda
Tel +250-591312
Mobile 00250-03294514




              Christian
              Zimmermann
              <christian.zimmerma                                             To
              nn at uconn.edu>               ashimeles at worldbank.org
                                                                              cc
              02/06/2009 09:44 PM
                                                                         Subject
                                          [RePEc] Your monthly statistics










Abebe Shimeles,


this is a monthly message to inform you about the visibility of
your works through RePEc. This message also contains information on
how to update your profile.

There are now 700,000 items listed on RePEc. Read more RePEc news on
blog, including a feature on Jose Barrueco, who provide you with the
citation analysis, and on changes to the way multiple affiliations
are treated in the rankings.
http://blog.repec.org/

For additional frequently asked questions, see http://authors.repec.org/FAQ.


Watch further down in this message for new citations to your works we have
uncovered.

Your ranking analysis, along with links to your profile pages on the
various RePEc services, is available at:
http://ideas.repec.org/cgi-bin/rank.cgi?psh19&lmUW

This link is valid only for a month. You can directly check
for new items you could add to your profile here:
http://authors.repec.org/?login=ashimeles at worldbank.org

Your profile currently contains 11 items, among them 8 papers, 3 articles.
Below are some traffic statistics for all these items, as provided by
LogEc. More details for each of your works are available directly at
http://logec.repec.org/RAS/psh19.htm

                 Abstract     File
                  views     downloads
Last month       145        35
Last 3 months    412        91
Last 12 months   1415       373
Since start      3761       1089

We have found the following citations to your works during the last month:

- Bigsten, Arne & Shimeles, Abebe, 2004.
"Dynamics of Poverty in Ethiopia,"
Working Papers UNU-WIDER Research Paper , World Institute for Development
Economic Research (UNU-WIDER).

cited in:
** - Zhang, Xiaobo & Rockmore, Marc & Chamberlin, Jordan, 2007.
"A typology for vulnerability and agriculture in Sub-Saharan Africa:,"
IFPRI Discussion Papers 734, International Food Policy Research Institute
(IFPRI).

** - Rogg, Christian, 2006.
"Asset Portfolios in Africa: Evidence from Rural Ethiopia,"
Working Papers RP2006/145, World Institute for Development Economic Research
(UNU-WIDER).

- Bigsten, Arne & Kebede, Bereket & Shimeles, Abebe & Taddesse, Mekonnen, 2003.
"Growth and Poverty Reduction in Ethiopia: Evidence from Household Panel
Surveys," World Development, Elsevier, vol. 31(1), pages 87-106, January.

cited in:
** - David Sahn & Stephen Younger, 2005.
"Improvements in children?s health: Does inequality matter?," Journal of
Economic Inequality, Springer, vol. 3(2), pages 125-143, August.

- Bigsten, Arne & Shimeles, Abebe, 2004.
"Prospects for 'Pro-Poor' Growth in Africa,"
Working Papers UNU-WIDER Research Paper , World Institute for Development
Economic Research (UNU-WIDER).

cited in:
** - Resnick, Danielle & Birner, Regina, 2006.
"Does good governance contribute to pro-poor growth?: a review of the evidence
from cross-country studies,"
DSGD discussion papers 30, International Food Policy Research Institute (IFPRI).

** - Resnick, Danielle & Birner, Regina, 2005.
"Does Good Governance Contribute to Pro-poor Growth?: A Conceptual Framework and
Empirical Evidence from Cross-Country Studies,"
Proceedings of the German Development Economics Conference, Kiel 2005 5, Verein
f?r Socialpolitik, Research Committee Development Economics.


Note that your profile on IDEAS may not yet reflect these new citations due to
the rotation schedule for the web site update. If any of these citations does
not appear to be correct, please log into your profile, and then click on
citations to make appropriate adjustments. You may also find additional
citations to approve for which we had a lower match confidence.

I encourage you to check from time to time on RePEc for new items
in the database you can claim authorship for, and keep your contact
information current. This is the only way to add new works to your
profile, this is not done automatically. Just use the direct link
http://authors.repec.org/?login=ashimeles at worldbank.org

New items are added continuously, be it from existing working papers
series and journals or from new ones contributing to the database.
And encourage your colleagues to do so as well. There are now over
19,000 authors registered through RePEc!

If you have questions, consult the FAQ mentioned above. But do not
hesitate to contact me for any question and encourage others
to register with RePEc!

Christian Zimmermann
RePEc Team
Department of Economics
University of Connecticut






From krichel at openlib.org  Wed Feb 11 03:40:18 2009
From: krichel at openlib.org (Thomas Krichel)
Date: Wed, 11 Feb 2009 02:40:18 -0600
Subject: [RAS] papers disappearing, "abdele problem"
In-Reply-To: <Pine.LNX.4.64.0902101526260.3066@fondue.econ.uconn.edu>
References: <Pine.LNX.4.64.0902101526260.3066@fondue.econ.uconn.edu>
Message-ID: <20090211084017.GB29121@openlib.org>

  Christian Zimmermann writes

> This is not the first time this happens: accepted papers get dropped from 
> profiles for no apparent reason and attempts to put them back in fail.
 
  I presume that means that they have no longer been in the database.

  It is this paper

Finance and poverty in Ethiopia: household level analysis
template-type: ReDIF-Paper 1.0
Author-name: Geda, Alemayehu
Author-name: Shimeles, Abebe
Author-name: Zerfu, Daniel
Title: Finance and Poverty in Ethiopia: A Household Level Analysis
Creation-Date: 2006
Number:  RP2006/51
Length: 26 pages
Keywords: finance, Ethiopia, Africa, poverty, consumption smoothing
File-URL: http://www.wider.unu.edu/stc/repec/pdfs/rp2006/rp2006-51.pdf
Handle: RePEc:unu:wpaper:RP2006-51


> It is only when I do a updareq that items are available again for
> claiming.  This has already happened several times for the AER.
>
> This time, it was RePEc:unu:wpaper


aras at nebka:/home/adrepec/RePEc/remo/unu/wpaper$ rech .
- rech v1.0.1 -- ReDIF files checker -
        by Ivan Kurmanov (kurmanov at openlib.org)

configuration: 
        redif.spec file   : /usr/local/share/perl/5.8.8/ReDIF/redif.spec
        redif.spec version: $revision$-5.8
        ReDIF home dir    : not identified
        local data dir    : 

No ReDIF home setting found/identified

Checking: .
going into directory: .
file ./wpaper4.rdf: OK (76)
file ./wpaper3.rdf: OK (90)
file ./wpaper5.rdf: OK (90)
file ./wpaper8.rdf: OK (107)
file ./wpaper2.rdf: OK (127)
file ./wpaper1.rdf: OK (147)
file ./wpaper9.rdf: OK (4)
file ./wpaper7.rdf: 
> template-type: ReDIF-Paper 1.0 
> Title: Assessing the Aid Allocation and Debt Sustainability Framework: Working Towards Incentive Compatible Aid Contracts
> Creation-Date: 2007
> Number: UNU-WIDER Research Paper RP2007/33
> Length: 28 pages 
> Keywords: foreign aid, economic development, aid allocation, debt sustainability
> File-URL: http://www.wider.unu.edu/stc/repec/pdfs/rp2007/rp2007-33.pdf
> Handle: RePEc:unu:wpaper:RP2007-33
> Abstract: This paper criticizes the current International Development Association (IDA) aid allocation and debt sustainability framework on the grounds of their over-reliance on the country policy and institutional assessment (CPIA) as the guiding criterion. It argues that CPIA-centred allocation of aid fails to introduce an incentives structure supportive of a genuine donor-recipient partnership, conducive to development. Further, it claims that the CPIA-dependent debt thresholds-central to the new debt sustainability framework-effectively submit sustainability concerns to the policy performance prerogatives of the aid allocation system. Resting on a thin empirical basis, such approach fails to take due account of low-income countries' vulnerability to exogenous shocks, as a key determinant of debt distress. As an alternative to the current CPIA-based scheme, the paper outlines the key features of a state-contingent mechanism, guiding both aid allocation and debt sustainability analysis.
> 

Error (line 462): Required attribute 'author-name' is absent in template of type 'redif-paper 1.0'

file ./wpaper6.rdf: OK (165)


  I doubt the problem is there. But it could be that, for
  example, they change a handle, but the file date is not
  changed, and the file size is not changed, and the update
  is not often enough despite this. Here is a significant
  change I made in 


#
# RePEc:
/home/aras/acis/bin/updareq RePEc / 31556926
# ACIS userdata:
/home/aras/acis/bin/updareq ACIS / 31556926
# citec:
/home/aras/acis/bin/updareq citec / 31556926


  31556926 is, roughly the number of seconds in a year.
  Ivan had this set to the number of secords in a week,
  meaning that nebka's rid crawled through the entire RePEc
  once a week, a considerable load on the machine. 
  So I reduced this to once a year, a drastic reduction.
  I made that change at the time we had the i/o problem
  that was due to a broken disk and that you claimed came
  from overusing the disk.

  Maybe these numbers should be set to once a month.


  Cheers,

  Thomas Krichel                    http://openlib.org/home/krichel
                                RePEc:per:1965-06-05:thomas_krichel
                                               skype: thomaskrichel


From krichel at openlib.org  Wed Feb 11 03:44:34 2009
From: krichel at openlib.org (Thomas Krichel)
Date: Wed, 11 Feb 2009 02:44:34 -0600
Subject: [RAS] papers disappearing, "abdele problem"
In-Reply-To: <20090211084017.GB29121@openlib.org>
References: <Pine.LNX.4.64.0902101526260.3066@fondue.econ.uconn.edu>
	<20090211084017.GB29121@openlib.org>
Message-ID: <20090211084434.GA29328@openlib.org>

  Thomas Krichel writes

> Here is a significant change I made in 
> 

  in acis/bin/crontab.daily


  Cheers,

  Thomas Krichel                    http://openlib.org/home/krichel
                                RePEc:per:1965-06-05:thomas_krichel
                                               skype: thomaskrichel


From christian.zimmermann at uconn.edu  Wed Feb 11 07:25:28 2009
From: christian.zimmermann at uconn.edu (Christian Zimmermann)
Date: Wed, 11 Feb 2009 07:25:28 -0500 (EST)
Subject: [RAS] papers disappearing, "abdele problem"
In-Reply-To: <20090211084017.GB29121@openlib.org>
References: <Pine.LNX.4.64.0902101526260.3066@fondue.econ.uconn.edu>
	<20090211084017.GB29121@openlib.org>
Message-ID: <Pine.LNX.4.64.0902110723310.3066@fondue.econ.uconn.edu>

That should solve the issue if it is the same problem as on my checking 
for new stuff. I have a database with checksums for rdf files, and if a 
file disappears and reappears, then it will not notice that it is back. 
But everyfile gets checked once a month just in case.

But that would not have explained what happened with the AER.



Christian Zimmermann                                     FIGUGEGL!
Department of Economics
University of Connecticut
341 Mansfield Road, Unit 1063
Storrs, CT 06269-1063
http://ideas.repec.org/zimm/   christian.zimmermann at uconn.edu
http://ideas.repec.org/e/pzi1.html

On Wed, 11 Feb 2009, Thomas Krichel wrote:

>
>  Christian Zimmermann writes
>
>> This is not the first time this happens: accepted papers get dropped from
>> profiles for no apparent reason and attempts to put them back in fail.
>
>  I presume that means that they have no longer been in the database.
>
>  It is this paper
>
> Finance and poverty in Ethiopia: household level analysis
> template-type: ReDIF-Paper 1.0
> Author-name: Geda, Alemayehu
> Author-name: Shimeles, Abebe
> Author-name: Zerfu, Daniel
> Title: Finance and Poverty in Ethiopia: A Household Level Analysis
> Creation-Date: 2006
> Number:  RP2006/51
> Length: 26 pages
> Keywords: finance, Ethiopia, Africa, poverty, consumption smoothing
> File-URL: http://www.wider.unu.edu/stc/repec/pdfs/rp2006/rp2006-51.pdf
> Handle: RePEc:unu:wpaper:RP2006-51
>
>
>> It is only when I do a updareq that items are available again for
>> claiming.  This has already happened several times for the AER.
>>
>> This time, it was RePEc:unu:wpaper
>
>
> aras at nebka:/home/adrepec/RePEc/remo/unu/wpaper$ rech .
> - rech v1.0.1 -- ReDIF files checker -
>        by Ivan Kurmanov (kurmanov at openlib.org)
>
> configuration:
>        redif.spec file   : /usr/local/share/perl/5.8.8/ReDIF/redif.spec
>        redif.spec version: $revision$-5.8
>        ReDIF home dir    : not identified
>        local data dir    :
>
> No ReDIF home setting found/identified
>
> Checking: .
> going into directory: .
> file ./wpaper4.rdf: OK (76)
> file ./wpaper3.rdf: OK (90)
> file ./wpaper5.rdf: OK (90)
> file ./wpaper8.rdf: OK (107)
> file ./wpaper2.rdf: OK (127)
> file ./wpaper1.rdf: OK (147)
> file ./wpaper9.rdf: OK (4)
> file ./wpaper7.rdf:
>> template-type: ReDIF-Paper 1.0
>> Title: Assessing the Aid Allocation and Debt Sustainability Framework: Working Towards Incentive Compatible Aid Contracts
>> Creation-Date: 2007
>> Number: UNU-WIDER Research Paper RP2007/33
>> Length: 28 pages
>> Keywords: foreign aid, economic development, aid allocation, debt sustainability
>> File-URL: http://www.wider.unu.edu/stc/repec/pdfs/rp2007/rp2007-33.pdf
>> Handle: RePEc:unu:wpaper:RP2007-33
>> Abstract: This paper criticizes the current International Development Association (IDA) aid allocation and debt sustainability framework on the grounds of their over-reliance on the country policy and institutional assessment (CPIA) as the guiding criterion. It argues that CPIA-centred allocation of aid fails to introduce an incentives structure supportive of a genuine donor-recipient partnership, conducive to development. Further, it claims that the CPIA-dependent debt thresholds-central to the new debt sustainability framework-effectively submit sustainability concerns to the policy performance prerogatives of the aid allocation system. Resting on a thin empirical basis, such approach fails to take due account of low-income countries' vulnerability to exogenous shocks, as a key determinant of debt distress. As an alternative to the current CPIA-based scheme, the paper outlines the key features of a state-contingent mechanism, guiding both aid allocation and debt sustainability analysis.
>>
>
> Error (line 462): Required attribute 'author-name' is absent in template of type 'redif-paper 1.0'
>
> file ./wpaper6.rdf: OK (165)
>
>
>  I doubt the problem is there. But it could be that, for
>  example, they change a handle, but the file date is not
>  changed, and the file size is not changed, and the update
>  is not often enough despite this. Here is a significant
>  change I made in
>
>
> #
> # RePEc:
> /home/aras/acis/bin/updareq RePEc / 31556926
> # ACIS userdata:
> /home/aras/acis/bin/updareq ACIS / 31556926
> # citec:
> /home/aras/acis/bin/updareq citec / 31556926
>
>
>  31556926 is, roughly the number of seconds in a year.
>  Ivan had this set to the number of secords in a week,
>  meaning that nebka's rid crawled through the entire RePEc
>  once a week, a considerable load on the machine.
>  So I reduced this to once a year, a drastic reduction.
>  I made that change at the time we had the i/o problem
>  that was due to a broken disk and that you claimed came
>  from overusing the disk.
>
>  Maybe these numbers should be set to once a month.
>
>
>  Cheers,
>
>  Thomas Krichel                    http://openlib.org/home/krichel
>                                RePEc:per:1965-06-05:thomas_krichel
>                                               skype: thomaskrichel
>

From krichel at openlib.org  Wed Feb 11 08:57:39 2009
From: krichel at openlib.org (Thomas Krichel)
Date: Wed, 11 Feb 2009 07:57:39 -0600
Subject: [RAS] papers disappearing, "abdele problem"
In-Reply-To: <Pine.LNX.4.64.0902110723310.3066@fondue.econ.uconn.edu>
References: <Pine.LNX.4.64.0902101526260.3066@fondue.econ.uconn.edu>
	<20090211084017.GB29121@openlib.org>
	<Pine.LNX.4.64.0902110723310.3066@fondue.econ.uconn.edu>
Message-ID: <20090211135739.GA6081@openlib.org>

  Christian Zimmermann writes

> That should solve the issue if it is the same problem as on my checking  
> for new stuff. I have a database with checksums for rdf files, and if a  
> file disappears and reappears, then it will not notice that it is back.  
> But everyfile gets checked once a month just in case.


  I have taken the same approach now

#
# Data Updates
#
# RePEc:
/home/aras/acis/bin/updareq RePEc / 2592000
# ACIS userdata:
/home/aras/acis/bin/updareq ACIS / 2592000
# citec:
/home/aras/acis/bin/updareq citec / 2592000


> But that would not have explained what happened with the AER.

  One mystery at a time.


  Cheers,

  Thomas Krichel                    http://openlib.org/home/krichel
                                RePEc:per:1965-06-05:thomas_krichel
                                               skype: thomaskrichel


From christian.zimmermann at uconn.edu  Sat Feb 14 16:01:25 2009
From: christian.zimmermann at uconn.edu (Christian Zimmermann)
Date: Sat, 14 Feb 2009 16:01:25 -0500 (EST)
Subject: [RAS] Frustration
Message-ID: <Pine.LNX.4.64.0902141558410.18392@fondue.econ.uconn.edu>

I am getting really frustrated with some templates that just refuse to 
load into RAS.

This case is about Frank Westermann who cannot get 
RePEc:bin:bpeajo:v:34:y:2003:i:2003-2:p:1-112 into his profile. I applied 
updareq to bin/bpeajo and to bin/bpeajo/BPEA_2003_02_Tornell.rdf multiple 
times, to no effect. I am at a loss now, as this has been dragging for 
several weeks now.

NB: put my email in response to guarantee that I see it.

Christian Zimmermann                                     FIGUGEGL!
Department of Economics
University of Connecticut
341 Mansfield Road, Unit 1063
Storrs, CT 06269-1063
http://ideas.repec.org/zimm/   christian.zimmermann at uconn.edu
http://ideas.repec.org/e/pzi1.html


From krichel at openlib.org  Sat Feb 14 16:37:39 2009
From: krichel at openlib.org (Thomas Krichel)
Date: Sat, 14 Feb 2009 15:37:39 -0600
Subject: [RAS] Frustration
In-Reply-To: <Pine.LNX.4.64.0902141558410.18392@fondue.econ.uconn.edu>
References: <Pine.LNX.4.64.0902141558410.18392@fondue.econ.uconn.edu>
Message-ID: <20090214213739.GA4457@openlib.org>

  Christian Zimmermann writes

> I am getting really frustrated with some templates that just refuse to  
> load into RAS.
>
> This case is about Frank Westermann who cannot get  
> RePEc:bin:bpeajo:v:34:y:2003:i:2003-2:p:1-112 into his profile. I applied 
> updareq to bin/bpeajo and to bin/bpeajo/BPEA_2003_02_Tornell.rdf multiple 
> times, to no effect. I am at a loss now, as this has been dragging for  
> several weeks now.

  From the log, when I try it

Sat Feb 14 16:06:29 2009  request:
 source: /home/aras/acis/bin/updareq [31834]
 collection: RePEc
 update: bin/bpeajo/BPEA_2003_02_Tornell.rdf ()
U DATAFILE_START: bin/bpeajo/BPEA_2003_02_Tornell.rdf
file: bin/bpeajo/BPEA_2003_02_01.rdf
no need to check it to draw conclusions
the record is still there
U DATAFILE_FINISH: bin/bpeajo/BPEA_2003_02_Tornell.rdf
Sat Feb 14 16:06:29 2009 processed bin/bpeajo/BPEA_2003_02_Tornell.rdf in RePEc
Sat Feb 14 16:06:29 2009 time:  0 wallclock secs ( 0.24 usr +  0.01 sys =  0.25 CPU)


 I have never seen

no need to check it to draw conclusions
the record is still there

  before.


  It does not appear that the record is in the database 

aras at nebka:~$ mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 72470
Server version: 5.0.32-Debian_7etch8-log Debian etch distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> use rdb;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select id from resources where id like "repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112";
Empty set (0.00 sec)

mysql> select id from resources where id = "repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112";
Empty set (0.00 sec)

mysql> select id from resources where id like "repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112%";
Empty set (0.00 sec)

  In phpmyadmin, running 

SELECT *  FROM `resources` WHERE `id` LIKE CONVERT(_utf8 'repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112' USING latin1) COLLATE latin1_swedish_ci

  gives an empby set, and so does

SELECT *  FROM `resources` WHERE `id` LIKE CONVERT(_utf8 'repec:bin:bpeajol:%' USING latin1) COLLATE latin1_swedish_ci


  In the code aras at nebka:~/acis/lib/RePEc/Index/History/Handle.pm


   if ( $status ) { # will queue
        p "will check it";
        push @current, $_;
        $files_to_check -> {$fn} = 1;

      }
      else {
        p "no need to check it to draw conclusions";

        # Is that file known to contain a record with the same id?
        # CONSISTENCY CHECK

        my $frec = $UPDATE -> get_file_record( $fn );
        if ( $frec ) {
          my $present_there;
          my $list = $frec -> templates_list;
          foreach ( @$list ) {
            if ( $_ eq $id ) {
              $present_there = 1;
            }
          }
          if ( $present_there ) {
            p "the record is still there";
            push @current, $_;

          }
          else {
            p "the record is no longer there";
            push @lost_present_file, $fn;
        }
        else {
          p "the file is no longer there";
          push @lost_present_file, $fn;
        }
      }
    }

  It seems to think the record is there, but is not.


  Cheers,

  Thomas Krichel                    http://openlib.org/home/krichel
                                RePEc:per:1965-06-05:thomas_krichel
                                               skype: thomaskrichel


From duraley at gmail.com  Sun Feb 15 19:34:02 2009
From: duraley at gmail.com (Ivan Kurmanov)
Date: Mon, 16 Feb 2009 02:34:02 +0200
Subject: [RAS] Frustration
In-Reply-To: <20090214213739.GA4457@openlib.org>
References: <Pine.LNX.4.64.0902141558410.18392@fondue.econ.uconn.edu>
	<20090214213739.GA4457@openlib.org>
Message-ID: <f46ffd910902151634v2901b730rdaf717d88fa2fc2b@mail.gmail.com>

Sorry about that, the error really means: the handle of the record in
question is a duplicate of another handle, in this case, of the one
that is used in a different file: bin/bpeajo/BPEA_2003_02_01.rdf.  And
that file does not have to be checked again (to see if that is a
conflict), because it was ready relatively recently and hasn't changed
since. Therefore RePEc::Index can safely draw the conclusion that the
handle is still in conflict and, therefore, it is excluded from the
processing.

Sometimes the decision about the conflict is deferred until the second
file is checked.

-ivan

On Sat, Feb 14, 2009 at 11:37 PM, Thomas Krichel <krichel at openlib.org> wrote:
>  Christian Zimmermann writes
>
>> I am getting really frustrated with some templates that just refuse to
>> load into RAS.
>>
>> This case is about Frank Westermann who cannot get
>> RePEc:bin:bpeajo:v:34:y:2003:i:2003-2:p:1-112 into his profile. I applied
>> updareq to bin/bpeajo and to bin/bpeajo/BPEA_2003_02_Tornell.rdf multiple
>> times, to no effect. I am at a loss now, as this has been dragging for
>> several weeks now.
>
>  From the log, when I try it
>
> Sat Feb 14 16:06:29 2009  request:
>  source: /home/aras/acis/bin/updareq [31834]
>  collection: RePEc
>  update: bin/bpeajo/BPEA_2003_02_Tornell.rdf ()
> U DATAFILE_START: bin/bpeajo/BPEA_2003_02_Tornell.rdf
> file: bin/bpeajo/BPEA_2003_02_01.rdf
> no need to check it to draw conclusions
> the record is still there
> U DATAFILE_FINISH: bin/bpeajo/BPEA_2003_02_Tornell.rdf
> Sat Feb 14 16:06:29 2009 processed bin/bpeajo/BPEA_2003_02_Tornell.rdf in RePEc
> Sat Feb 14 16:06:29 2009 time:  0 wallclock secs ( 0.24 usr +  0.01 sys =  0.25 CPU)
>
>
>  I have never seen
>
> no need to check it to draw conclusions
> the record is still there
>
>  before.
>
>
>  It does not appear that the record is in the database
>
> aras at nebka:~$ mysql
> Welcome to the MySQL monitor.  Commands end with ; or \g.
> Your MySQL connection id is 72470
> Server version: 5.0.32-Debian_7etch8-log Debian etch distribution
>
> Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
>
> mysql> use rdb;
> Reading table information for completion of table and column names
> You can turn off this feature to get a quicker startup with -A
>
> Database changed
> mysql> select id from resources where id like "repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112";
> Empty set (0.00 sec)
>
> mysql> select id from resources where id = "repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112";
> Empty set (0.00 sec)
>
> mysql> select id from resources where id like "repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112%";
> Empty set (0.00 sec)
>
>  In phpmyadmin, running
>
> SELECT *  FROM `resources` WHERE `id` LIKE CONVERT(_utf8 'repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112' USING latin1) COLLATE latin1_swedish_ci
>
>  gives an empby set, and so does
>
> SELECT *  FROM `resources` WHERE `id` LIKE CONVERT(_utf8 'repec:bin:bpeajol:%' USING latin1) COLLATE latin1_swedish_ci
>
>
>  In the code aras at nebka:~/acis/lib/RePEc/Index/History/Handle.pm
>
>
>   if ( $status ) { # will queue
>        p "will check it";
>        push @current, $_;
>        $files_to_check -> {$fn} = 1;
>
>      }
>      else {
>        p "no need to check it to draw conclusions";
>
>        # Is that file known to contain a record with the same id?
>        # CONSISTENCY CHECK
>
>        my $frec = $UPDATE -> get_file_record( $fn );
>        if ( $frec ) {
>          my $present_there;
>          my $list = $frec -> templates_list;
>          foreach ( @$list ) {
>            if ( $_ eq $id ) {
>              $present_there = 1;
>            }
>          }
>          if ( $present_there ) {
>            p "the record is still there";
>            push @current, $_;
>
>          }
>          else {
>            p "the record is no longer there";
>            push @lost_present_file, $fn;
>        }
>        else {
>          p "the file is no longer there";
>          push @lost_present_file, $fn;
>        }
>      }
>    }
>
>  It seems to think the record is there, but is not.
>
>
>  Cheers,
>
>  Thomas Krichel                    http://openlib.org/home/krichel
>                                RePEc:per:1965-06-05:thomas_krichel
>                                               skype: thomaskrichel
>
> _______________________________________________
> RAS-run mailing list
> RAS-run at lists.openlib.org
> http://lists.openlib.org/cgi-bin/mailman/listinfo/ras-run
>


From duraley at gmail.com  Sun Feb 15 19:36:38 2009
From: duraley at gmail.com (Ivan Kurmanov)
Date: Mon, 16 Feb 2009 02:36:38 +0200
Subject: [RAS] Frustration
In-Reply-To: <f46ffd910902151634v2901b730rdaf717d88fa2fc2b@mail.gmail.com>
References: <Pine.LNX.4.64.0902141558410.18392@fondue.econ.uconn.edu>
	<20090214213739.GA4457@openlib.org>
	<f46ffd910902151634v2901b730rdaf717d88fa2fc2b@mail.gmail.com>
Message-ID: <f46ffd910902151636u1cbfd5a8j87c8bc95c7307b72@mail.gmail.com>

I should add that RAS (ACIS) has a couple of special screens to query
the RePEc::Index (update daemon) database. There you can check the
state of a record by it's handle (is it in conflict? in which file it
is expected to be or was last seen? (at what position?) and so on). I
don't remember any details, but double check the documentation, it
should be mentioned somewhere. If not, check screens.xml for something
related.

-ivan

On Mon, Feb 16, 2009 at 2:34 AM, Ivan Kurmanov <duraley at gmail.com> wrote:
> Sorry about that, the error really means: the handle of the record in
> question is a duplicate of another handle, in this case, of the one
> that is used in a different file: bin/bpeajo/BPEA_2003_02_01.rdf.  And
> that file does not have to be checked again (to see if that is a
> conflict), because it was ready relatively recently and hasn't changed
> since. Therefore RePEc::Index can safely draw the conclusion that the
> handle is still in conflict and, therefore, it is excluded from the
> processing.
>
> Sometimes the decision about the conflict is deferred until the second
> file is checked.
>
> -ivan
>
> On Sat, Feb 14, 2009 at 11:37 PM, Thomas Krichel <krichel at openlib.org> wrote:
>>  Christian Zimmermann writes
>>
>>> I am getting really frustrated with some templates that just refuse to
>>> load into RAS.
>>>
>>> This case is about Frank Westermann who cannot get
>>> RePEc:bin:bpeajo:v:34:y:2003:i:2003-2:p:1-112 into his profile. I applied
>>> updareq to bin/bpeajo and to bin/bpeajo/BPEA_2003_02_Tornell.rdf multiple
>>> times, to no effect. I am at a loss now, as this has been dragging for
>>> several weeks now.
>>
>>  From the log, when I try it
>>
>> Sat Feb 14 16:06:29 2009  request:
>>  source: /home/aras/acis/bin/updareq [31834]
>>  collection: RePEc
>>  update: bin/bpeajo/BPEA_2003_02_Tornell.rdf ()
>> U DATAFILE_START: bin/bpeajo/BPEA_2003_02_Tornell.rdf
>> file: bin/bpeajo/BPEA_2003_02_01.rdf
>> no need to check it to draw conclusions
>> the record is still there
>> U DATAFILE_FINISH: bin/bpeajo/BPEA_2003_02_Tornell.rdf
>> Sat Feb 14 16:06:29 2009 processed bin/bpeajo/BPEA_2003_02_Tornell.rdf in RePEc
>> Sat Feb 14 16:06:29 2009 time:  0 wallclock secs ( 0.24 usr +  0.01 sys =  0.25 CPU)
>>
>>
>>  I have never seen
>>
>> no need to check it to draw conclusions
>> the record is still there
>>
>>  before.
>>
>>
>>  It does not appear that the record is in the database
>>
>> aras at nebka:~$ mysql
>> Welcome to the MySQL monitor.  Commands end with ; or \g.
>> Your MySQL connection id is 72470
>> Server version: 5.0.32-Debian_7etch8-log Debian etch distribution
>>
>> Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
>>
>> mysql> use rdb;
>> Reading table information for completion of table and column names
>> You can turn off this feature to get a quicker startup with -A
>>
>> Database changed
>> mysql> select id from resources where id like "repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112";
>> Empty set (0.00 sec)
>>
>> mysql> select id from resources where id = "repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112";
>> Empty set (0.00 sec)
>>
>> mysql> select id from resources where id like "repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112%";
>> Empty set (0.00 sec)
>>
>>  In phpmyadmin, running
>>
>> SELECT *  FROM `resources` WHERE `id` LIKE CONVERT(_utf8 'repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112' USING latin1) COLLATE latin1_swedish_ci
>>
>>  gives an empby set, and so does
>>
>> SELECT *  FROM `resources` WHERE `id` LIKE CONVERT(_utf8 'repec:bin:bpeajol:%' USING latin1) COLLATE latin1_swedish_ci
>>
>>
>>  In the code aras at nebka:~/acis/lib/RePEc/Index/History/Handle.pm
>>
>>
>>   if ( $status ) { # will queue
>>        p "will check it";
>>        push @current, $_;
>>        $files_to_check -> {$fn} = 1;
>>
>>      }
>>      else {
>>        p "no need to check it to draw conclusions";
>>
>>        # Is that file known to contain a record with the same id?
>>        # CONSISTENCY CHECK
>>
>>        my $frec = $UPDATE -> get_file_record( $fn );
>>        if ( $frec ) {
>>          my $present_there;
>>          my $list = $frec -> templates_list;
>>          foreach ( @$list ) {
>>            if ( $_ eq $id ) {
>>              $present_there = 1;
>>            }
>>          }
>>          if ( $present_there ) {
>>            p "the record is still there";
>>            push @current, $_;
>>
>>          }
>>          else {
>>            p "the record is no longer there";
>>            push @lost_present_file, $fn;
>>        }
>>        else {
>>          p "the file is no longer there";
>>          push @lost_present_file, $fn;
>>        }
>>      }
>>    }
>>
>>  It seems to think the record is there, but is not.
>>
>>
>>  Cheers,
>>
>>  Thomas Krichel                    http://openlib.org/home/krichel
>>                                RePEc:per:1965-06-05:thomas_krichel
>>                                               skype: thomaskrichel
>>
>> _______________________________________________
>> RAS-run mailing list
>> RAS-run at lists.openlib.org
>> http://lists.openlib.org/cgi-bin/mailman/listinfo/ras-run
>>
>


From krichel at openlib.org  Sat Feb 21 15:37:22 2009
From: krichel at openlib.org (Thomas Krichel)
Date: Sat, 21 Feb 2009 14:37:22 -0600
Subject: [RAS] utf8 reference strings
In-Reply-To: <Pine.WNT.4.64.0902211219050.3420@bibsoc65.bib_tarongers.es>
References: <Pine.WNT.4.64.0902211219050.3420@bibsoc65.bib_tarongers.es>
Message-ID: <20090221203722.GB1017@openlib.org>

  Jose Manuel Barrueco writes

> I've managed to see correct utf8 characters in:
>
> CitEc database -> AMF files
>
> but now the problem is in the ACIS database.

  A bit of background here. JMBC and I have been working on the issue
  of citations lost between RAS and CitEc. It appears that there are
  issues in the character sets of the reference string
  (refstring). CitEc produced latin-1 refstrings and stuck them into
  the AMF files. We changed the column of the reference to utf-8.

> There, the character set 
> used in the citations table is still latin1. I've re-processed a  
> document with problems in characters (RePEc:mar:volksw:200425) to test 
> the changes. Before, the characters were ok in ACIS but wrong in CitEc. 
> Not we have the problem in the other side. Try for instance:
>
> mysql> select clid,cnid,ostring from citations where ostring like 
> "SALMON, P. (2003), As%";
>
> Should we change the character set for ACIS too?

  I think this will have to be done.  I am not sure how it is 
  best to be done and hope that Ivan can advice. We can change
  the columns to utf-8 and reload all the citations. Maybe at 
  this stage we will remove the link to the citations screen
  temporarily so that we have a chance to test things.

  Cheers,

  Thomas Krichel                    http://openlib.org/home/krichel
                                RePEc:per:1965-06-05:thomas_krichel
                                               skype: thomaskrichel


From barrueco at uv.es  Fri Feb 27 04:00:18 2009
From: barrueco at uv.es (Jose Manuel Barrueco)
Date: Fri, 27 Feb 2009 10:00:18 +0100
Subject: [RAS] utf8 reference strings
In-Reply-To: <20090221203722.GB1017@openlib.org>
References: <Pine.WNT.4.64.0902211219050.3420@bibsoc65.bib_tarongers.es>
	<20090221203722.GB1017@openlib.org>
Message-ID: <Pine.WNT.4.64.0902270958360.3852@bibsoc65.bib_tarongers.es>


 	If nobody has comments or suggestion on that I would suggest to go 
ahead with the change latin-1 to utf8. If we proceede like in CitEc it 
should not be necesary to reload all citations since the proporcion of 
references afected is quite small...


On Sat, 21 Feb 2009, Thomas Krichel wrote:

>  Jose Manuel Barrueco writes
>
>> I've managed to see correct utf8 characters in:
>>
>> CitEc database -> AMF files
>>
>> but now the problem is in the ACIS database.
>
>  A bit of background here. JMBC and I have been working on the issue
>  of citations lost between RAS and CitEc. It appears that there are
>  issues in the character sets of the reference string
>  (refstring). CitEc produced latin-1 refstrings and stuck them into
>  the AMF files. We changed the column of the reference to utf-8.
>
>> There, the character set
>> used in the citations table is still latin1. I've re-processed a
>> document with problems in characters (RePEc:mar:volksw:200425) to test
>> the changes. Before, the characters were ok in ACIS but wrong in CitEc.
>> Not we have the problem in the other side. Try for instance:
>>
>> mysql> select clid,cnid,ostring from citations where ostring like
>> "SALMON, P. (2003), As%";
>>
>> Should we change the character set for ACIS too?
>
>  I think this will have to be done.  I am not sure how it is
>  best to be done and hope that Ivan can advice. We can change
>  the columns to utf-8 and reload all the citations. Maybe at
>  this stage we will remove the link to the citations screen
>  temporarily so that we have a chance to test things.
>
>  Cheers,
>
>  Thomas Krichel                    http://openlib.org/home/krichel
>                                RePEc:per:1965-06-05:thomas_krichel
>                                               skype: thomaskrichel
>
>


---
Jos? Manuel Barrueco				http://www.uv.es/=barrueco

From krichel at openlib.org  Fri Feb 27 17:55:53 2009
From: krichel at openlib.org (Thomas Krichel)
Date: Fri, 27 Feb 2009 16:55:53 -0600
Subject: [RAS] utf8 reference strings
In-Reply-To: <Pine.WNT.4.64.0902270958360.3852@bibsoc65.bib_tarongers.es>
References: <Pine.WNT.4.64.0902211219050.3420@bibsoc65.bib_tarongers.es>
	<20090221203722.GB1017@openlib.org>
	<Pine.WNT.4.64.0902270958360.3852@bibsoc65.bib_tarongers.es>
Message-ID: <20090227225553.GE13189@openlib.org>

  Jose Manuel Barrueco writes
>
> 	If nobody has comments or suggestion on that I would suggest to go  
> ahead with the change latin-1 to utf8. If we proceede like in CitEc it  
> should not be necesary to reload all citations since the proporcion of  
> references afected is quite small...

  I have the following log of a skype chat with Ivan. He seems to
  think that the change should be done.

da? meaning we can change the colon type 
[5:12:44 PM]  ???? ?. ????????: hi Thomas
[5:12:50 PM]  ???? ?. ????????: :)
[5:13:05 PM]  ???? ?. ????????: since you asked...
[5:13:13 PM]  ???? ?. ????????: it should be in utf 8 already
[5:13:24 PM] Thomas Krichel: it is not
[5:13:25 PM]  ???? ?. ????????: it should have been in utf8 from the start
[5:13:29 PM]  ???? ?. ????????: how do you know?
[5:13:39 PM] Thomas Krichel: we looked it up in phpmyadmin
[5:13:55 PM]  ???? ?. ????????: ok
[5:14:07 PM]  ???? ?. ????????: but that's just the mysql type
[5:14:34 PM]  ???? ?. ????????: it matters for comparisons and string functions
[5:14:37 PM] Thomas Krichel: JMBC was amazed taht you turned his latin-1 to utf-8 somehowe
[5:14:49 PM]  ???? ?. ????????: ?
[5:15:25 PM] Thomas Krichel: you took his latin-1 in amf, and made it somewho utf-8
[5:15:33 PM] Thomas Krichel: we did not see a conversion.
[5:16:02 PM]  ???? ?. ????????: did he put latin-1 in AMF? did it have <?xml declaration with encoding='latin-1' ?
[5:16:10 PM] Thomas Krichel: no
[5:16:14 PM] Thomas Krichel: apparently not
[5:16:28 PM] Thomas Krichel: the whole thing is very strange.
[5:17:27 PM] Thomas Krichel: I don't want to bother you with this, because this is not an emmergency, so I think we can just cange the type and see what comes out.
[5:17:48 PM] Thomas Krichel: I will also check the acis code that creates the tables.
[5:18:03 PM]  ???? ?. ????????: the fact that something in ACIS database does not have UTF8 type is wrong, but I don't think it is responsible for any real trouble you are having
[5:18:31 PM] Thomas Krichel: no, the origin was latin-1 from jmbc
[5:18:46 PM]  ???? ?. ????????: i might be wrong, (as things change), but this type does not by itself causes any charset conversion
[5:18:59 PM] Thomas Krichel: correct.
[5:19:12 PM] Thomas Krichel: but it will convert if you change the colon type
[5:19:18 PM] Thomas Krichel: I think.
[5:19:35 PM]  ???? ?. ????????: i doubt; re-check that
[5:20:05 PM] Thomas Krichel: I don't know how to check ,but the query took a very long time to run when we made the change on mutabor.
[5:20:14 PM] Thomas Krichel: so it must have been converting something.
[5:20:31 PM]  ???? ?. ????????: "I don't know how to check" -- documentation
[5:21:11 PM] Thomas Krichel: I know I have to lookup the docementation. I have not seen it in there last time I looked, but I did not investigate.
[5:21:38 PM]  ???? ?. ????????: in this case I meant the mysql database
[5:22:07 PM]  ???? ?. ????????: which would definitely answer if the data conversion takes place if you change the column charset
[5:23:10 PM] Thomas Krichel: I know you mean the database.
[5:23:23 PM] Thomas Krichel: I am not sure what command phpmyadmin runs.
[5:26:15 PM] Thomas Krichel: one think for sure is that under latin-1 the column does not take the utf-8 output that JMBC produces now.
[5:26:43 PM] Thomas Krichel: I think we can close the matter here so far.
[5:26:52 PM] Thomas Krichel: I hope you are doing fine.
[5:27:07 PM]  ???? ?. ????????: alright. thanks, Thomas, I'm ok

  I suggest that JMBC proceeds monday morning, I will be at hand monday
  to watch out for problems.

  Cheers,

  Thomas Krichel                    http://openlib.org/home/krichel
                                RePEc:per:1965-06-05:thomas_krichel
                                               skype: thomaskrichel


