Briefcase

Aggregate 1.2.0, Briefcase 1.2

I have Aggregate running on a local server. I can pull records from the
server using Briefcase. I then want to update the form. I am not changing
any of the database structure. Then I want to push those records back to
the form on the server. I can not seem to get this to work?

Andy

Aggregate 1.2 allows you to update the form. Aggregate checks the form to
make that nothing has changed that would cause problems in the database. If
Aggregate doesn't reject the form then there is no need to use briefcase to
accomplish form changes. If Aggregate rejects the change you are most
likely changing something that will cause database issues.

Waylon

··· On Fri, Sep 28, 2012 at 8:47 AM, Andrew Faust wrote:

Aggregate 1.2.0, Briefcase 1.2

I have Aggregate running on a local server. I can pull records from the
server using Briefcase. I then want to update the form. I am not changing
any of the database structure. Then I want to push those records back to
the form on the server. I can not seem to get this to work?

Andy

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

So that I am clear if I update the form and do not change the
database structure I will not lose any existing records that are currently
on the server.

··· On Friday, September 28, 2012 11:35:15 AM UTC-5, Waylon Brunette wrote: > > Aggregate 1.2 allows you to update the form. Aggregate checks the form to > make that nothing has changed that would cause problems in the database. If > Aggregate doesn't reject the form then there is no need to use briefcase to > accomplish form changes. If Aggregate rejects the change you are most > likely changing something that will cause database issues. > > Waylon > > On Fri, Sep 28, 2012 at 8:47 AM, Andrew Faust <afa...@ncwrpc.org wrote: > >> Aggregate 1.2.0, Briefcase 1.2 >> >> I have Aggregate running on a local server. I can pull records from the >> server using Briefcase. I then want to update the form. I am not changing >> any of the database structure. Then I want to push those records back to >> the form on the server. I can not seem to get this to work? >> >> Andy >> >> -- >> Post: opend...@googlegroups.com >> Unsubscribe: opendatakit...@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en >> > >

Yes that is correct. Aggregate should reject any form that does not match
it's current database store (if an ID already exists).

It's always a good idea to back up your data anyway; however, you can
upload a revised form and Aggregate will check whether it can accept it or
not.

··· On Fri, Sep 28, 2012 at 10:23 AM, Andrew Faust wrote:

So that I am clear if I update the form and do not change the
database structure I will not lose any existing records that are currently
on the server.

On Friday, September 28, 2012 11:35:15 AM UTC-5, Waylon Brunette wrote:

Aggregate 1.2 allows you to update the form. Aggregate checks the form to
make that nothing has changed that would cause problems in the database. If
Aggregate doesn't reject the form then there is no need to use briefcase to
accomplish form changes. If Aggregate rejects the change you are most
likely changing something that will cause database issues.

Waylon

On Fri, Sep 28, 2012 at 8:47 AM, Andrew Faust afa...@ncwrpc.org wrote:

Aggregate 1.2.0, Briefcase 1.2

I have Aggregate running on a local server. I can pull records from the
server using Briefcase. I then want to update the form. I am not changing
any of the database structure. Then I want to push those records back to
the form on the server. I can not seem to get this to work?

Andy

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@**googlegroups.com
Options: http://groups.google.com/**group/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

I tried this and it does not work. You are correct it is rejected if the
form ID already exists. So if I update the form to a new form ID it adds
it to the server. How do I update an existing form. Sorry I just do not
follow. The only way to do it is to delete the form and add it again. If
I do this my data will be gone.

Thanks
Andy

··· On Friday, September 28, 2012 1:16:36 PM UTC-5, Waylon Brunette wrote: > > Yes that is correct. Aggregate should reject any form that does not match > it's current database store (if an ID already exists). > > It's always a good idea to back up your data anyway; however, you can > upload a revised form and Aggregate will check whether it can accept it or > not. > > On Fri, Sep 28, 2012 at 10:23 AM, Andrew Faust <afa...@ncwrpc.org wrote: > >> So that I am clear if I update the form and do not change the >> database structure I will not lose any existing records that are currently >> on the server. >> >> >> On Friday, September 28, 2012 11:35:15 AM UTC-5, Waylon Brunette wrote: >> >>> Aggregate 1.2 allows you to update the form. Aggregate checks the form >>> to make that nothing has changed that would cause problems in the database. >>> If Aggregate doesn't reject the form then there is no need to use briefcase >>> to accomplish form changes. If Aggregate rejects the change you are most >>> likely changing something that will cause database issues. >>> >>> Waylon >>> >>> On Fri, Sep 28, 2012 at 8:47 AM, Andrew Faust wrote: >>> >>>> Aggregate 1.2.0, Briefcase 1.2 >>>> >>>> I have Aggregate running on a local server. I can pull records from >>>> the server using Briefcase. I then want to update the form. I am not >>>> changing any of the database structure. Then I want to push those records >>>> back to the form on the server. I can not seem to get this to work? >>>> >>>> Andy >>>> >>>> -- >>>> Post: opend...@googlegroups.com >>>> Unsubscribe: opendatakit...@**googlegroups.com >>>> Options: http://groups.google.com/**group/opendatakit?hl=en >>>> >>> >>> -- >> Post: opend...@googlegroups.com >> Unsubscribe: opendatakit...@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en >> > >

Aggregate has detected a change in your form that will affect the database.
Therefore it's rejecting it as it thinks it should be a new form not an
update to the original form.

Waylon

··· On Fri, Sep 28, 2012 at 11:25 AM, Andrew Faust wrote:

I tried this and it does not work. You are correct it is rejected if the
form ID already exists. So if I update the form to a new form ID it adds
it to the server. How do I update an existing form. Sorry I just do not
follow. The only way to do it is to delete the form and add it again. If
I do this my data will be gone.

Thanks
Andy

On Friday, September 28, 2012 1:16:36 PM UTC-5, Waylon Brunette wrote:

Yes that is correct. Aggregate should reject any form that does not match
it's current database store (if an ID already exists).

It's always a good idea to back up your data anyway; however, you can
upload a revised form and Aggregate will check whether it can accept it or
not.

On Fri, Sep 28, 2012 at 10:23 AM, Andrew Faust afa...@ncwrpc.org wrote:

So that I am clear if I update the form and do not change the
database structure I will not lose any existing records that are currently
on the server.

On Friday, September 28, 2012 11:35:15 AM UTC-5, Waylon Brunette wrote:

Aggregate 1.2 allows you to update the form. Aggregate checks the form
to make that nothing has changed that would cause problems in the database.
If Aggregate doesn't reject the form then there is no need to use briefcase
to accomplish form changes. If Aggregate rejects the change you are most
likely changing something that will cause database issues.

Waylon

On Fri, Sep 28, 2012 at 8:47 AM, Andrew Faust afa...@ncwrpc.orgwrote:

Aggregate 1.2.0, Briefcase 1.2

I have Aggregate running on a local server. I can pull records from
the server using Briefcase. I then want to update the form. I am not
changing any of the database structure. Then I want to push those records
back to the form on the server. I can not seem to get this to work?

Andy

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@**googlegroups.**com
Options: http://groups.google.com/**group**/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@**googlegroups.com
Options: http://groups.google.com/**group/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

My guess is you changed something in the bindings that would affect the
database definition.

··· On Fri, Sep 28, 2012 at 12:24 PM, W. Brunette wrote:

Aggregate has detected a change in your form that will affect the
database. Therefore it's rejecting it as it thinks it should be a new form
not an update to the original form.

Waylon

On Fri, Sep 28, 2012 at 11:25 AM, Andrew Faust afaust@ncwrpc.org wrote:

I tried this and it does not work. You are correct it is rejected if the
form ID already exists. So if I update the form to a new form ID it adds
it to the server. How do I update an existing form. Sorry I just do not
follow. The only way to do it is to delete the form and add it again. If
I do this my data will be gone.

Thanks
Andy

On Friday, September 28, 2012 1:16:36 PM UTC-5, Waylon Brunette wrote:

Yes that is correct. Aggregate should reject any form that does not
match it's current database store (if an ID already exists).

It's always a good idea to back up your data anyway; however, you can
upload a revised form and Aggregate will check whether it can accept it or
not.

On Fri, Sep 28, 2012 at 10:23 AM, Andrew Faust afa...@ncwrpc.orgwrote:

So that I am clear if I update the form and do not change the
database structure I will not lose any existing records that are currently
on the server.

On Friday, September 28, 2012 11:35:15 AM UTC-5, Waylon Brunette wrote:

Aggregate 1.2 allows you to update the form. Aggregate checks the form
to make that nothing has changed that would cause problems in the database.
If Aggregate doesn't reject the form then there is no need to use briefcase
to accomplish form changes. If Aggregate rejects the change you are most
likely changing something that will cause database issues.

Waylon

On Fri, Sep 28, 2012 at 8:47 AM, Andrew Faust afa...@ncwrpc.orgwrote:

Aggregate 1.2.0, Briefcase 1.2

I have Aggregate running on a local server. I can pull records from
the server using Briefcase. I then want to update the form. I am not
changing any of the database structure. Then I want to push those records
back to the form on the server. I can not seem to get this to work?

Andy

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@**googlegroups.**com
Options: http://groups.google.com/**group**/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@**googlegroups.com
Options: http://groups.google.com/**group/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

The only thing I change was adding something to the cascading selects. And
updated a hint. So you are telling me that if I did not change the
database the form should have the same form ID should overwrite and update
the existing form and keep my data records????

Andy

··· On Friday, September 28, 2012 2:25:46 PM UTC-5, Waylon Brunette wrote: > > My guess is you changed something in the bindings that would affect the > database definition. > > On Fri, Sep 28, 2012 at 12:24 PM, W. Brunette <wbru...@gmail.com wrote: > >> Aggregate has detected a change in your form that will affect the >> database. Therefore it's rejecting it as it thinks it should be a new form >> not an update to the original form. >> >> Waylon >> >> >> On Fri, Sep 28, 2012 at 11:25 AM, Andrew Faust <afa...@ncwrpc.org wrote: >> >>> I tried this and it does not work. You are correct it is rejected if >>> the form ID already exists. So if I update the form to a new form ID it >>> adds it to the server. How do I update an existing form. Sorry I just do >>> not follow. The only way to do it is to delete the form and add it again. >>> If I do this my data will be gone. >>> >>> Thanks >>> Andy >>> >>> >>> On Friday, September 28, 2012 1:16:36 PM UTC-5, Waylon Brunette wrote: >>> >>>> Yes that is correct. Aggregate should reject any form that does not >>>> match it's current database store (if an ID already exists). >>>> >>>> It's always a good idea to back up your data anyway; however, you can >>>> upload a revised form and Aggregate will check whether it can accept it or >>>> not. >>>> >>>> On Fri, Sep 28, 2012 at 10:23 AM, Andrew Faust wrote: >>>> >>>>> So that I am clear if I update the form and do not change the >>>>> database structure I will not lose any existing records that are currently >>>>> on the server. >>>>> >>>>> >>>>> On Friday, September 28, 2012 11:35:15 AM UTC-5, Waylon Brunette wrote: >>>>> >>>>>> Aggregate 1.2 allows you to update the form. Aggregate checks the >>>>>> form to make that nothing has changed that would cause problems in the >>>>>> database. If Aggregate doesn't reject the form then there is no need to use >>>>>> briefcase to accomplish form changes. If Aggregate rejects the change you >>>>>> are most likely changing something that will cause database issues. >>>>>> >>>>>> Waylon >>>>>> >>>>>> On Fri, Sep 28, 2012 at 8:47 AM, Andrew Faust wrote: >>>>>> >>>>>>> Aggregate 1.2.0, Briefcase 1.2 >>>>>>> >>>>>>> I have Aggregate running on a local server. I can pull records from >>>>>>> the server using Briefcase. I then want to update the form. I am not >>>>>>> changing any of the database structure. Then I want to push those records >>>>>>> back to the form on the server. I can not seem to get this to work? >>>>>>> >>>>>>> Andy >>>>>>> >>>>>>> -- >>>>>>> Post: opend...@googlegroups.com >>>>>>> Unsubscribe: opendatakit...@**googlegroups.**com >>>>>>> Options: http://groups.google.com/**group**/opendatakit?hl=en >>>>>>> >>>>>> >>>>>> -- >>>>> Post: opend...@googlegroups.com >>>>> Unsubscribe: opendatakit...@**googlegroups.com >>>>> Options: http://groups.google.com/**group/opendatakit?hl=en >>>>> >>>> >>>> -- >>> Post: opend...@googlegroups.com >>> Unsubscribe: opendatakit...@googlegroups.com >>> Options: http://groups.google.com/group/opendatakit?hl=en >>> >> >> >

Yes, that is correct that feature was added in Aggregate 1.2 (it was
actually a patch contributed by a member of the community):

http://code.google.com/p/opendatakit/wiki/AggregateReleaseNotes
From 1.2 release notes:
"Form definition files and media attachments can now be altered and those
changes uploaded to the ODK Aggregate server. The server still maintains
only one version of the form, and all alterations must not affect the
number of questions in the form or change the data type of any field (e.g.,
from int to decimal or string, etc.). "

We worked with the community member to be extremely strict on what is
allowed because we did not want to have the possibility of the database
getting messed up because we know how important everyone's data is.

It maybe something with the cascade changes that we did not anticipate but
if the change has database implications then it's doing it's job. The hint
should definitely have not affect, not sure about the cascading selects did
anything change in the bindings section?

Waylon

··· On Fri, Sep 28, 2012 at 12:37 PM, Andrew Faust wrote:

The only thing I change was adding something to the cascading selects.
And updated a hint. So you are telling me that if I did not change the
database the form should have the same form ID should overwrite and update
the existing form and keep my data records????

Andy

On Friday, September 28, 2012 2:25:46 PM UTC-5, Waylon Brunette wrote:

My guess is you changed something in the bindings that would affect the
database definition.

On Fri, Sep 28, 2012 at 12:24 PM, W. Brunette wbru...@gmail.com wrote:

Aggregate has detected a change in your form that will affect the
database. Therefore it's rejecting it as it thinks it should be a new form
not an update to the original form.

Waylon

On Fri, Sep 28, 2012 at 11:25 AM, Andrew Faust afa...@ncwrpc.orgwrote:

I tried this and it does not work. You are correct it is rejected if
the form ID already exists. So if I update the form to a new form ID it
adds it to the server. How do I update an existing form. Sorry I just do
not follow. The only way to do it is to delete the form and add it again.
If I do this my data will be gone.

Thanks
Andy

On Friday, September 28, 2012 1:16:36 PM UTC-5, Waylon Brunette wrote:

Yes that is correct. Aggregate should reject any form that does not
match it's current database store (if an ID already exists).

It's always a good idea to back up your data anyway; however, you can
upload a revised form and Aggregate will check whether it can accept it or
not.

On Fri, Sep 28, 2012 at 10:23 AM, Andrew Faust afa...@ncwrpc.orgwrote:

So that I am clear if I update the form and do not change the
database structure I will not lose any existing records that are currently
on the server.

On Friday, September 28, 2012 11:35:15 AM UTC-5, Waylon Brunette wrote:

Aggregate 1.2 allows you to update the form. Aggregate checks the
form to make that nothing has changed that would cause problems in the
database. If Aggregate doesn't reject the form then there is no need to use
briefcase to accomplish form changes. If Aggregate rejects the change you
are most likely changing something that will cause database issues.

Waylon

On Fri, Sep 28, 2012 at 8:47 AM, Andrew Faust afa...@ncwrpc.orgwrote:

Aggregate 1.2.0, Briefcase 1.2

I have Aggregate running on a local server. I can pull records
from the server using Briefcase. I then want to update the form. I am not
changing any of the database structure. Then I want to push those records
back to the form on the server. I can not seem to get this to work?

Andy

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@**googlegroups.com
Options: http://groups.google.com/**group****/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@**googlegroups.**com
Options: http://groups.google.com/**group**/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@**googlegroups.com
Options: http://groups.google.com/**group/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

OK I will keep working on it to see what I can come up with. No new fields
were added to the database, just another select in the cascading selects.
Oh well.

Andy

··· On Friday, September 28, 2012 2:44:39 PM UTC-5, Waylon Brunette wrote: > > Yes, that is correct that feature was added in Aggregate 1.2 (it was > actually a patch contributed by a member of the community): > > http://code.google.com/p/opendatakit/wiki/AggregateReleaseNotes > From 1.2 release notes: > "Form definition files and media attachments can now be altered and those > changes uploaded to the ODK Aggregate server. The server still maintains > only one version of the form, and all alterations must not affect the > number of questions in the form or change the data type of any field (e.g., > from int to decimal or string, etc.). " > > We worked with the community member to be extremely strict on what is > allowed because we did not want to have the possibility of the database > getting messed up because we know how important everyone's data is. > > It maybe something with the cascade changes that we did not anticipate but > if the change has database implications then it's doing it's job. The hint > should definitely have not affect, not sure about the cascading selects did > anything change in the bindings section? > > Waylon > > On Fri, Sep 28, 2012 at 12:37 PM, Andrew Faust <afa...@ncwrpc.org wrote: > >> The only thing I change was adding something to the cascading selects. >> And updated a hint. So you are telling me that if I did not change the >> database the form should have the same form ID should overwrite and update >> the existing form and keep my data records???? >> >> Andy >> >> >> On Friday, September 28, 2012 2:25:46 PM UTC-5, Waylon Brunette wrote: >> >>> My guess is you changed something in the bindings that would affect the >>> database definition. >>> >>> On Fri, Sep 28, 2012 at 12:24 PM, W. Brunette wrote: >>> >>>> Aggregate has detected a change in your form that will affect the >>>> database. Therefore it's rejecting it as it thinks it should be a new form >>>> not an update to the original form. >>>> >>>> Waylon >>>> >>>> >>>> On Fri, Sep 28, 2012 at 11:25 AM, Andrew Faust wrote: >>>> >>>>> I tried this and it does not work. You are correct it is rejected if >>>>> the form ID already exists. So if I update the form to a new form ID it >>>>> adds it to the server. How do I update an existing form. Sorry I just do >>>>> not follow. The only way to do it is to delete the form and add it again. >>>>> If I do this my data will be gone. >>>>> >>>>> Thanks >>>>> Andy >>>>> >>>>> >>>>> On Friday, September 28, 2012 1:16:36 PM UTC-5, Waylon Brunette wrote: >>>>> >>>>>> Yes that is correct. Aggregate should reject any form that does not >>>>>> match it's current database store (if an ID already exists). >>>>>> >>>>>> It's always a good idea to back up your data anyway; however, you can >>>>>> upload a revised form and Aggregate will check whether it can accept it or >>>>>> not. >>>>>> >>>>>> On Fri, Sep 28, 2012 at 10:23 AM, Andrew Faust wrote: >>>>>> >>>>>>> So that I am clear if I update the form and do not change the >>>>>>> database structure I will not lose any existing records that are currently >>>>>>> on the server. >>>>>>> >>>>>>> >>>>>>> On Friday, September 28, 2012 11:35:15 AM UTC-5, Waylon Brunette wrote: >>>>>>> >>>>>>>> Aggregate 1.2 allows you to update the form. Aggregate checks the >>>>>>>> form to make that nothing has changed that would cause problems in the >>>>>>>> database. If Aggregate doesn't reject the form then there is no need to use >>>>>>>> briefcase to accomplish form changes. If Aggregate rejects the change you >>>>>>>> are most likely changing something that will cause database issues. >>>>>>>> >>>>>>>> Waylon >>>>>>>> >>>>>>>> On Fri, Sep 28, 2012 at 8:47 AM, Andrew Faust wrote: >>>>>>>> >>>>>>>>> Aggregate 1.2.0, Briefcase 1.2 >>>>>>>>> >>>>>>>>> I have Aggregate running on a local server. I can pull records >>>>>>>>> from the server using Briefcase. I then want to update the form. I am not >>>>>>>>> changing any of the database structure. Then I want to push those records >>>>>>>>> back to the form on the server. I can not seem to get this to work? >>>>>>>>> >>>>>>>>> Andy >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Post: opend...@googlegroups.com >>>>>>>>> Unsubscribe: opendatakit...@**googlegroups.**co**m >>>>>>>>> Options: http://groups.google.com/**group****/opendatakit?hl=en >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> Post: opend...@googlegroups.com >>>>>>> Unsubscribe: opendatakit...@**googlegroups.**com >>>>>>> Options: http://groups.google.com/**group**/opendatakit?hl=en >>>>>>> >>>>>> >>>>>> -- >>>>> Post: opend...@googlegroups.com >>>>> Unsubscribe: opendatakit...@**googlegroups.com >>>>> Options: http://groups.google.com/**group/opendatakit?hl=en >>>>> >>>> >>>> >>> -- >> Post: opend...@googlegroups.com >> Unsubscribe: opendatakit...@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en >> > >

An easy test would be to download the form then reupload the same form.
Aggregate should allow that.

Waylon

··· On Fri, Sep 28, 2012 at 12:51 PM, Andrew Faust wrote:

OK I will keep working on it to see what I can come up with. No new
fields were added to the database, just another select in the cascading
selects. Oh well.

Andy

On Friday, September 28, 2012 2:44:39 PM UTC-5, Waylon Brunette wrote:

Yes, that is correct that feature was added in Aggregate 1.2 (it was
actually a patch contributed by a member of the community):

http://code.google.com/p/**opendatakit/wiki/**AggregateReleaseNoteshttp://code.google.com/p/opendatakit/wiki/AggregateReleaseNotes
From 1.2 release notes:
"Form definition files and media attachments can now be altered and those
changes uploaded to the ODK Aggregate server. The server still maintains
only one version of the form, and all alterations must not affect the
number of questions in the form or change the data type of any field (e.g.,
from int to decimal or string, etc.). "

We worked with the community member to be extremely strict on what is
allowed because we did not want to have the possibility of the database
getting messed up because we know how important everyone's data is.

It maybe something with the cascade changes that we did not anticipate
but if the change has database implications then it's doing it's job. The
hint should definitely have not affect, not sure about the cascading
selects did anything change in the bindings section?

Waylon

On Fri, Sep 28, 2012 at 12:37 PM, Andrew Faust afa...@ncwrpc.org wrote:

The only thing I change was adding something to the cascading selects.
And updated a hint. So you are telling me that if I did not change the
database the form should have the same form ID should overwrite and update
the existing form and keep my data records????

Andy

On Friday, September 28, 2012 2:25:46 PM UTC-5, Waylon Brunette wrote:

My guess is you changed something in the bindings that would affect the
database definition.

On Fri, Sep 28, 2012 at 12:24 PM, W. Brunette wbru...@gmail.comwrote:

Aggregate has detected a change in your form that will affect the
database. Therefore it's rejecting it as it thinks it should be a new form
not an update to the original form.

Waylon

On Fri, Sep 28, 2012 at 11:25 AM, Andrew Faust afa...@ncwrpc.orgwrote:

I tried this and it does not work. You are correct it is rejected if
the form ID already exists. So if I update the form to a new form ID it
adds it to the server. How do I update an existing form. Sorry I just do
not follow. The only way to do it is to delete the form and add it again.
If I do this my data will be gone.

Thanks
Andy

On Friday, September 28, 2012 1:16:36 PM UTC-5, Waylon Brunette wrote:

Yes that is correct. Aggregate should reject any form that does not
match it's current database store (if an ID already exists).

It's always a good idea to back up your data anyway; however, you
can upload a revised form and Aggregate will check whether it can accept it
or not.

On Fri, Sep 28, 2012 at 10:23 AM, Andrew Faust afa...@ncwrpc.orgwrote:

So that I am clear if I update the form and do not change the
database structure I will not lose any existing records that are currently
on the server.

On Friday, September 28, 2012 11:35:15 AM UTC-5, Waylon Brunette wrote:

Aggregate 1.2 allows you to update the form. Aggregate checks the
form to make that nothing has changed that would cause problems in the
database. If Aggregate doesn't reject the form then there is no need to use
briefcase to accomplish form changes. If Aggregate rejects the change you
are most likely changing something that will cause database issues.

Waylon

On Fri, Sep 28, 2012 at 8:47 AM, Andrew Faust afa...@ncwrpc.orgwrote:

Aggregate 1.2.0, Briefcase 1.2

I have Aggregate running on a local server. I can pull records
from the server using Briefcase. I then want to update the form. I am not
changing any of the database structure. Then I want to push those records
back to the form on the server. I can not seem to get this to work?

Andy

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@**googlegroups.**co****m
Options: http://groups.google.com/**group******/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@**googlegroups.com
Options: http://groups.google.com/**group****/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@**googlegroups.**com
Options: http://groups.google.com/**group**/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@**googlegroups.com
Options: http://groups.google.com/**group/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

Andy,

See the discussion of cascading-selects and versioning here:

http://opendatakit.org/help/form-design/cascading-selects/

Also, this subject was discussed here:

https://groups.google.com/forum/#!msg/opendatakit/qeyRcfrs1pU/z9skGE644sUJ

Are you sure, though, that you are using the versioning properly (i.e.,
including the version and bumping it up for the new version)? Again,
there's more on this in the first link above.

Best,

Chris

··· From my read, certain types of cascading-select changes should be allowed.

On Friday, September 28, 2012, Andrew Faust wrote:

OK I will keep working on it to see what I can come up with. No new
fields were added to the database, just another select in the cascading
selects. Oh well.

Andy

On Friday, September 28, 2012 2:44:39 PM UTC-5, Waylon Brunette wrote:

Yes, that is correct that feature was added in Aggregate 1.2 (it was
actually a patch contributed by a member of the community):

http://code.google.com/p/**opendatakit/wiki/**AggregateReleaseNoteshttp://code.google.com/p/opendatakit/wiki/AggregateReleaseNotes
From 1.2 release notes:
"Form definition files and media attachments can now be altered and those
changes uploaded to the ODK Aggregate server. The server still maintains
only one version of the form, and all alterations must not affect the
number of questions in the form or change the data type of any field (e.g.,
from int to decimal or string, etc.). "

We worked with the community member to be extremely strict on what is
allowed because we did not want to have the possibility of the database
getting messed up because we know how important everyone's data is.

It maybe something with the cascade changes that we did not anticipate
but if the change has database implications then it's doing it's job. The
hint should definitely have not affect, not sure about the cascading
selects did anything change in the bindings section?

Waylon

On Fri, Sep 28, 2012 at 12:37 PM, Andrew Faust afa...@ncwrpc.org wrote:

The only thing I change was adding something to the cascading selects.
And updated a hint. So you are telling me that if I did not change the
database the form should have the same form ID should overwrite and update
the existing form and keep my data records????

Andy

On Friday, September 28, 2012 2:25:46 PM UTC-5, Waylon Brunette wrote:

My guess is you changed something in the bindings that would affect the
database definition.

On Fri, Sep 28, 2012 at 12:24 PM, W. Brunette wbru...@gmail.com wrote:

Aggregate has detected a change in your form that will affect the
database. Therefore it's rejecting it as it thinks it should be a new form
not an update to the original form.

Waylon

On Fri, Sep 28, 2012 at 11:25 AM, Andrew Faust afa...@ncwrpc.org wrote:

I tried this and it does not work. You are correct it is rejected if the
form ID already exists. So if I update the form to a new form ID it adds
it to the server. How do I update an existing form. Sorry I just do not
follow. The only way to do it is to delete the form and add it again. If
I do this my data will be gone.

Thanks
Andy

On Friday, September 28, 2012 1:16:36 PM UTC-5, Waylon Brunette wrote:

Yes that is correct. Aggregate should reject any form that does not match
it's current database store (if an ID already exists).

It's always a good idea to back up your data anyway; however, you can
upload a revised form and Aggregate will check whether it can accept it or
not.

On Fri, Sep 28, 2012 at 10:23 AM, Andrew Faust afa...@ncwrpc.org wrote:

So that I am clear if I update the form and do not change the
database structure I will not lose any existing records that are currently
on the server.

On Friday, September 28, 2012 11:35:15 AM UTC-5, Waylon Brunette wrote:

Aggregate 1.2 allows you to update the form. Aggregate checks the form to
make that nothing has changed that would cause problems in the database. If
Aggregate doesn't reject the form then there is no need to use briefcase to
accomplish form changes. If Aggregate rejects the change you are most
likely changing something that will cause database issues.

Waylon

On Fri, Sep 28, 2012 at 8:47 AM, Andrew Faust afa...@ncwrpc.org wrote:

Aggregate 1.2.0, Briefcase 1.2

I have Aggregate running on a local server. I can pull records from the
server using Briefcase. I then want to update the form. I am not changing
any of the database structure. Then I want to push those records back to
the form on the server. I can not seem to get this to work?

Andy

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@**googlegroups.**co****m
Options: http://groups.google.com/**group******/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@**googlegroups.com
Options: http://groups.google.com/**group****/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@**googlegroups.**com
Options

--
Post: opendatakit@googlegroups.com <javascript:_e({}, 'cvml',
'opendatakit@googlegroups.com');>
Unsubscribe: opendatakit+unsubscribe@googlegroups.com <javascript:_e({},
'cvml', 'opendatakit%2Bunsubscribe@googlegroups.com');>
Options: http://groups.google.com/group/opendatakit?hl=en

OK after reading the links from Chris I found my problem. My XML form was
missing the version line after the form ID. The form was created using
XLSForm. I did not know that this line was needed. Once I added it to the
XML form work fine. Not sure if this is an issue with XLSForm and
cascading selects? Or just something that has not been updated since
cascading selects is something fairly new.

As always thanks again for everyone's help

Andy

··· On Friday, September 28, 2012 2:54:21 PM UTC-5, Christopher Robert wrote: > > Andy, > > See the discussion of cascading-selects and versioning here: > > http://opendatakit.org/help/form-design/cascading-selects/ > > Also, this subject was discussed here: > > https://groups.google.com/forum/#!msg/opendatakit/qeyRcfrs1pU/z9skGE644sUJ > > From my read, certain types of cascading-select changes should be allowed. > Are you sure, though, that you are using the versioning properly (i.e., > including the version and bumping it up for the new version)? Again, > there's more on this in the first link above. > > Best, > > Chris > > On Friday, September 28, 2012, Andrew Faust wrote: > >> OK I will keep working on it to see what I can come up with. No new >> fields were added to the database, just another select in the cascading >> selects. Oh well. >> >> Andy >> >> >> On Friday, September 28, 2012 2:44:39 PM UTC-5, Waylon Brunette wrote: >>> >>> Yes, that is correct that feature was added in Aggregate 1.2 (it was >>> actually a patch contributed by a member of the community): >>> >>> http://code.google.com/p/**opendatakit/wiki/**AggregateReleaseNotes >>> From 1.2 release notes: >>> "Form definition files and media attachments can now be altered and >>> those changes uploaded to the ODK Aggregate server. The server still >>> maintains only one version of the form, and all alterations must not affect >>> the number of questions in the form or change the data type of any field >>> (e.g., from int to decimal or string, etc.). " >>> >>> We worked with the community member to be extremely strict on what is >>> allowed because we did not want to have the possibility of the database >>> getting messed up because we know how important everyone's data is. >>> >>> It maybe something with the cascade changes that we did not anticipate >>> but if the change has database implications then it's doing it's job. The >>> hint should definitely have not affect, not sure about the cascading >>> selects did anything change in the bindings section? >>> >>> Waylon >>> >>> On Fri, Sep 28, 2012 at 12:37 PM, Andrew Faust wrote: >>> >>> The only thing I change was adding something to the cascading selects. >>> And updated a hint. So you are telling me that if I did not change the >>> database the form should have the same form ID should overwrite and update >>> the existing form and keep my data records???? >>> >>> Andy >>> >>> >>> On Friday, September 28, 2012 2:25:46 PM UTC-5, Waylon Brunette wrote: >>> >>> My guess is you changed something in the bindings that would affect the >>> database definition. >>> >>> On Fri, Sep 28, 2012 at 12:24 PM, W. Brunette wrote: >>> >>> Aggregate has detected a change in your form that will affect the >>> database. Therefore it's rejecting it as it thinks it should be a new form >>> not an update to the original form. >>> >>> Waylon >>> >>> >>> On Fri, Sep 28, 2012 at 11:25 AM, Andrew Faust wrote: >>> >>> I tried this and it does not work. You are correct it is rejected if >>> the form ID already exists. So if I update the form to a new form ID it >>> adds it to the server. How do I update an existing form. Sorry I just do >>> not follow. The only way to do it is to delete the form and add it again. >>> If I do this my data will be gone. >>> >>> Thanks >>> Andy >>> >>> >>> On Friday, September 28, 2012 1:16:36 PM UTC-5, Waylon Brunette wrote: >>> >>> Yes that is correct. Aggregate should reject any form that does not >>> match it's current database store (if an ID already exists). >>> >>> It's always a good idea to back up your data anyway; however, you can >>> upload a revised form and Aggregate will check whether it can accept it or >>> not. >>> >>> On Fri, Sep 28, 2012 at 10:23 AM, Andrew Faust wrote: >>> >>> So that I am clear if I update the form and do not change the >>> database structure I will not lose any existing records that are currently >>> on the server. >>> >>> >>> On Friday, September 28, 2012 11:35:15 AM UTC-5, Waylon Brunette wrote: >>> >>> Aggregate 1.2 allows you to update the form. Aggregate checks the form >>> to make that nothing has changed that would cause problems in the database. >>> If Aggregate doesn't reject the form then there is no need to use briefcase >>> to accomplish form changes. If Aggregate rejects the change you are most >>> likely changing something that will cause database issues. >>> >>> Waylon >>> >>> On Fri, Sep 28, 2012 at 8:47 AM, Andrew Faust wrote: >>> >>> Aggregate 1.2.0, Briefcase 1.2 >>> >>> I have Aggregate running on a local server. I can pull records from the >>> server using Briefcase. I then want to update the form. I am not changing >>> any of the database structure. Then I want to push those records back to >>> the form on the server. I can not seem to get this to work? >>> >>> Andy >>> >>> -- >>> Post: opend...@googlegroups.com >>> Unsubscribe: opendatakit...@**googlegroups.**co****m >>> Options: http://groups.google.com/**group******/opendatakit?hl=en >>> >>> >>> -- >>> Post: opend...@googlegroups.com >>> Unsubscribe: opendatakit...@**googlegroups.**co**m >>> Options: http://groups.google.com/**group****/opendatakit?hl=en >>> >>> >>> -- >>> Post: opend...@googlegroups.com >>> Unsubscribe: opendatakit...@**googlegroups.**com >>> Options >>> >>> -- >> Post: opendatakit@googlegroups.com >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en >> >

Andy,

I'm very happy to hear this! In fact, the latest XLSForm allows a version
column in the settings worksheet; the first row should be "version"
(without the quotes) and the second row should have the numeric version
code. That way, you don't have to hand-edit the XML.

Best,

Chris

··· On Saturday, September 29, 2012, Andrew Faust wrote:

OK after reading the links from Chris I found my problem. My XML form was
missing the version line after the form ID. The form was created using
XLSForm. I did not know that this line was needed. Once I added it to the
XML form work fine. Not sure if this is an issue with XLSForm and
cascading selects? Or just something that has not been updated since
cascading selects is something fairly new.

As always thanks again for everyone's help

Andy

On Friday, September 28, 2012 2:54:21 PM UTC-5, Christopher Robert wrote:

Andy,

See the discussion of cascading-selects and versioning here:

http://opendatakit.org/help/**form-design/cascading-selects/http://opendatakit.org/help/form-design/cascading-selects/

Also, this subject was discussed here:

https://groups.google.com/**forum/#!msg/opendatakit/**
qeyRcfrs1pU/z9skGE644sUJhttps://groups.google.com/forum/#!msg/opendatakit/qeyRcfrs1pU/z9skGE644sUJ

From my read, certain types of cascading-select changes should be allowed.
Are you sure, though, that you are using the versioning properly (i.e.,
including the version and bumping it up for the new version)? Again,
there's more on this in the first link above.

Best,

Chris

On Friday, September 28, 2012, Andrew Faust wrote:

OK I will keep working on it to see what I can come up with. No new
fields were added to the database, just another select in the cascading
selects. Oh well.

Andy

On Friday, September 28, 2012 2:44:39 PM UTC-5, Waylon Brunette wrote:

Yes, that is correct that feature was added in Aggregate 1.2 (it was
actually a patch contributed by a member of the community):

http://code.google.com/p/**opend**atakit/wiki/**AggregateReleaseNo**teshttp://code.google.com/p/opendatakit/wiki/AggregateReleaseNotes
From 1.2 release notes:
"Form definition files and media attachments can now be altered and those
changes uploaded to the ODK Aggregate server. The server still maintains
only one version of the form, and all alterations must not affect the
number of questions in the form or change the data type of any field (e.g.,
from int to decimal or string, etc.). "

We worked with the community member to be extremely strict on what is
allowed because we did not want to have the possibility of the database
getting messed up because we know how important everyone's data is.

It maybe something with the cascade changes that we did not anticipate but
if the change has database implications then it's doing it's job. The hint
should definitely have not affect, not sure about the cascading selects did
anything change in the bindings section?

Waylon

On Fri, Sep 28, 2012 at 12:37 PM, Andrew Faust afa...@ncwrpc.org wrote:

The only thing I change was adding something to the cascading selects.
And updated a hint. So you are telling me that if I did not change the
database the form should have the same form ID should overwrite and update
the existing form and keep my data records????

Andy

On Friday, September 28, 2012 2:25:46 PM UTC-5, Waylon Brunette wrote:

My guess is you changed something in the bindings that would affect the
database definition.

On Fri, Sep 28, 2012 at 12:24 PM, W. Brunette wbru...@gmail.com wrote:

Aggregate has detected a change in your form that will affect the
database. Therefore it's rejecting it as it thinks it should be a new form
not an update to the original form.

Waylon

On Fri, Sep 28, 2012 at 11:25 AM, Andrew Faust afa...@ncwrpc.org wrote:

I tried this and it does not work. You are correct it is rejected if the
form ID already exists. So if I update the form to a new form ID it adds
it to the server. How do I update an existing form. Sorry I just do not
follow. The only way to do it is to delete the form and add it again. If
I do this my data will be gone.

Thanks
Andy

On Friday, September 28, 2012 1:16:36 PM UTC-5, Waylon Brunette wrote:

Yes that is correct. Aggregate should reject any form that does not match
it's current database store (if an ID already exists).

It's always a good idea to back up your data anyway; however, you can
upload a revised form and Agg

--
Post: opendatakit@googlegroups.com <javascript:_e({}, 'cvml',
'opendatakit@googlegroups.com');>
Unsubscribe: opendatakit+unsubscribe@googlegroups.com <javascript:_e({},
'cvml', 'opendatakit%2Bunsubscribe@googlegroups.com');>
Options: http://groups.google.com/group/opendatakit?hl=en

maybe the sample xls file on the website should be updated to reflect this
change?

Thanks

··· On Saturday, September 29, 2012 9:06:30 AM UTC-5, Christopher Robert wrote: > > Andy, > > I'm very happy to hear this! In fact, the latest XLSForm allows a version > column in the settings worksheet; the first row should be "version" > (without the quotes) and the second row should have the numeric version > code. That way, you don't have to hand-edit the XML. > > Best, > > Chris > > On Saturday, September 29, 2012, Andrew Faust wrote: > >> OK after reading the links from Chris I found my problem. My XML form >> was missing the version line after the form ID. The form was created using >> XLSForm. I did not know that this line was needed. Once I added it to the >> XML form work fine. Not sure if this is an issue with XLSForm and >> cascading selects? Or just something that has not been updated since >> cascading selects is something fairly new. >> >> As always thanks again for everyone's help >> >> Andy >> >> On Friday, September 28, 2012 2:54:21 PM UTC-5, Christopher Robert wrote: >> >> Andy, >> >> See the discussion of cascading-selects and versioning here: >> >> http://opendatakit.org/help/**form-design/cascading-selects/ >> >> Also, this subject was discussed here: >> >> https://groups.google.com/**forum/#!msg/opendatakit/** >> qeyRcfrs1pU/z9skGE644sUJ >> >> From my read, certain types of cascading-select changes should be >> allowed. Are you sure, though, that you are using the versioning properly >> (i.e., including the version and bumping it up for the new version)? Again, >> there's more on this in the first link above. >> >> Best, >> >> Chris >> >> On Friday, September 28, 2012, Andrew Faust wrote: >> >> OK I will keep working on it to see what I can come up with. No new >> fields were added to the database, just another select in the cascading >> selects. Oh well. >> >> Andy >> >> >> On Friday, September 28, 2012 2:44:39 PM UTC-5, Waylon Brunette wrote: >> >> Yes, that is correct that feature was added in Aggregate 1.2 (it was >> actually a patch contributed by a member of the community): >> >> http://code.google.com/p/**opend**atakit/wiki/**AggregateReleaseNo**tes >> From 1.2 release notes: >> "Form definition files and media attachments can now be altered and those >> changes uploaded to the ODK Aggregate server. The server still maintains >> only one version of the form, and all alterations must not affect the >> number of questions in the form or change the data type of any field (e.g., >> from int to decimal or string, etc.). " >> >> We worked with the community member to be extremely strict on what is >> allowed because we did not want to have the possibility of the database >> getting messed up because we know how important everyone's data is. >> >> It maybe something with the cascade changes that we did not anticipate >> but if the change has database implications then it's doing it's job. The >> hint should definitely have not affect, not sure about the cascading >> selects did anything change in the bindings section? >> >> Waylon >> >> On Fri, Sep 28, 2012 at 12:37 PM, Andrew Faust wrote: >> >> The only thing I change was adding something to the cascading selects. >> And updated a hint. So you are telling me that if I did not change the >> database the form should have the same form ID should overwrite and update >> the existing form and keep my data records???? >> >> Andy >> >> >> On Friday, September 28, 2012 2:25:46 PM UTC-5, Waylon Brunette wrote: >> >> My guess is you changed something in the bindings that would affect the >> database definition. >> >> On Fri, Sep 28, 2012 at 12:24 PM, W. Brunette wrote: >> >> Aggregate has detected a change in your form that will affect the >> database. Therefore it's rejecting it as it thinks it should be a new form >> not an update to the original form. >> >> Waylon >> >> >> On Fri, Sep 28, 2012 at 11:25 AM, Andrew Faust wrote: >> >> I tried this and it does not work. You are correct it is rejected if the >> form ID already exists. So if I update the form to a new form ID it adds >> it to the server. How do I update an existing form. Sorry I just do not >> follow. The only way to do it is to delete the form and add it again. If >> I do this my data will be gone. >> >> Thanks >> Andy >> >> >> On Friday, September 28, 2012 1:16:36 PM UTC-5, Waylon Brunette wrote: >> >> Yes that is correct. Aggregate should reject any form that does not match >> it's current database store (if an ID already exists). >> >> It's always a good idea to back up your data anyway; however, you can >> upload a revised form and Agg >> >> -- >> Post: opendatakit@googlegroups.com >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en >> >