I ran another test, this time with trace turned on on the server. I’m attaching the document containing the trace in case that might be helpful. It’s pretty long, and the spacing got screwed up, but maybe it will be helpful. I’d like to learn how to read one of these; do we have any resources for that?
In my “rookie-ness”, let me ask this question. When you say “repository”, I am thinking that you’re referring the place where my source is being stored and versioned, ie, source control. In my case, that would be Unfuddle. So, when I do something like “Sync with repository”, I’m doing that with Unfuddle. Is that the repository that you’re referring to?
I’m also “kinda”, well, ok, “really”, confused as to why when I’m running in the Smart Client (this is all in Developer, by the way), I’m getting an error message relating to the Repository. I guess that might go back to what this error message is actually saying. So, when it says that it “could not resolve column public:tblproofs#tblproofs”, is it telling me that there is something wrong in the Servoy metadata? If so, is there a way to look at that? Or am I, once again, completely oblivious?
Servoy uses a database server connection called “repository” when deployed. My earlier instructions are for when you get deployment errors of the missing objects kind.
The default Servoy Developer install creates a “repository” database connection. While in developer, its only use is as a simple team sharing system:
Since you are doing the recommended approach to code versioning, I would just turn off the repository database connection or delete it altogether. Also check that “servoy.application_server.startRepositoryAsTeamProvider” is set to false in your admin settings.
In other words, in Servoy Developer the repository database connection is not needed. Servoy Server is exactly the opposite: it requires the repository database connection.
I think I figured out what’s causing the problem, although not why I’m getting a message from the repository.
A bit of background.
In this part of the system, I’m using 3 main tables. Artwork, Proofs, and Editions. Artwork is one to many Proofs, and Proofs are one to many Editions. Now because of a quirk in the original system I started with, the Edition records have the keys of the artwork records, so I can get from the artwork records directly to the editions if I want, without traversing the Proof records.
Now, the “main” form I’m working with uses the Artwork table as its datasource. There is a tabpanel on that form, with a subform on it that uses the Editions table as its datasource. If I put no relation on the subform in the tabpanel, I don’t get the abend. If I use an artwork_to_editions relation, I get no abend. If I use an artwork_to_proofs.proofs_to_editions relation, I get the error I documented.
I think what’s happening is that because neither form is making use of the proofs table, there’s no Proof table key for the relation to use, and it gets very unhappy. Why it’s generating the error message that it’s giving, with its reference to the repository, I have no idea. But I have a working solution of just using the artwork_to_editions relation.
I’d like to be able to look at the keys being used in the relation, but I’m not sure if I can grab them before the abend occurs. Using an event on the subform is probably too late. There’s only one event on the tabpanel, and that’s onChange. I might try catching it there. Depends on when they actually fire in relation to when the relation gets filled and used.
I just thought I’d write this up in case anyone else happens to come across a problem like this.
Thanks again for the help. Everyone, have a good day/afternoon/evening/night
I am getting the same error. Sometimes…not always…
I am using servoy 7.
My case is also the same that Ron’s case.
Also I have this kind of relation : relationName evnt_evnt_program_item_to_evnt_program_item_product.evnt_evnt_program_item_product_to_evnt_program_article
Fout in relatie
com.servoy.j2db.persistence.RepositoryException: java.lang.IllegalStateException: Could not resolve column etc etc