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?
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.
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?
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<javascript:> > > 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?
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?
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.
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<javascript:> > > 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?
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.
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?
On Fri, Sep 28, 2012 at 12:24 PM, W. Brunette <wbrune...@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?
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????
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<javascript:> > > 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<javascript:> >> > 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?
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?
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?
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.
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<javascript:> > > 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?
On Fri, Sep 28, 2012 at 12:51 PM, Andrew Faust <afa...@ncwrpc.org> 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):
>> 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?
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.
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):
>> 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?
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.
> 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):
>>> 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?
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.
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:
> 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):
> 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
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:
>> 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):
>> 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
