Page 1 of 1

Database Editor Stopped Working

PostPosted: Sun Mar 19, 2017 2:30 am
by bcusick
This is one that I've never seen before... the built-in database editor just isn't working.

When you click on a field - the details (auto-enter, properties, etc) do not show up. Same if I add a field. When I even add a field - I can't change the datatype (the dropdown shows up, but if I select "INTEGER" it refuses to change).

Anyone else ever seen this?

2017-03-18_17-24-20.png
2017-03-18_17-24-20.png (5.42 KiB) Viewed 7501 times

Re: Database Editor Stopped Working

PostPosted: Sun Mar 19, 2017 10:33 am
by Bernd.N
Hi Bob,

that never happend on my side in the last 3.5 years. As software just is not deciding to behave different every day, the question would be "What did change just before the first incident?"
And in case the setup of a clean new Servoy does not require too much work, that might be less effort than a search for the reason.

Finally I assume you already did a computer re-start, as that heals issues sometimes.

Re: Database Editor Stopped Working

PostPosted: Sun Mar 19, 2017 6:53 pm
by bcusick
Hey Bernd,

Thanks. Yeah, I figured I would have to re-install - but it was really strange. I didn't even do anything out of the ordinary - and I've NEVER seen this (and I've been working with this tool a LONG time)...

I restarted the machine, restarted Servoy (3 times) - and still the issue persists.

Re-install solved the issue (of course)... was just curious if anyone had seen this before.

Re: Database Editor Stopped Working

PostPosted: Sun Mar 19, 2017 6:58 pm
by bcusick
SO, I take it back. I started with a fresh install and workspace - and no problems. I got the editor.

I tried something - I rather than just exporting the solution with all the data - I just copied over the entire database folder to the new install, and copied my servoy.properties file.

No problem - I created a "scratch" solution, and was able to edit the tables just fine.

Then I opened my other workspace - and WHAM - it happened again. Nothing in the editor worked.

Re: Database Editor Stopped Working

PostPosted: Sun Mar 19, 2017 7:17 pm
by bcusick
It turned out to be the resources. Somehow they got screwed. That's why it worked in the new workspace and not the old.

Re: Database Editor Stopped Working

PostPosted: Sun Mar 19, 2017 8:03 pm
by Bernd.N
So you exported your Servoy solution and imported it into a new workspace, thus creating a fresh resources database?

Re: Database Editor Stopped Working

PostPosted: Sun Mar 19, 2017 8:25 pm
by bcusick
I just synchronized my database servers - and created new DBI files.

The bad news is - I had forgotten to upload my existing resources project to the SVN, so I'm now having to go back through every table and reset the auto-enter values, UUID flags, etc.

Re: Database Editor Stopped Working

PostPosted: Sun Mar 19, 2017 9:41 pm
by Bernd.N
Regarding auto-enter, I prefer to do that with help of an own table with a tenant_id.
The advantage for me is that I have a complete overview of all auto-enter-values in just one table, and it can be adjusted differently for each customer.

Re: Database Editor Stopped Working

PostPosted: Mon Mar 20, 2017 8:47 pm
by bcusick
Huh. That's a really interesting idea!

You can't set the UUID flags that way - but for auto-enter data that's a good idea.

I've also used entity methods - even global methods (back in the old days) tied to the OnRecordInsert event (auto -enter current tenant UUID, for example).

Re: Database Editor Stopped Working

PostPosted: Mon Mar 20, 2017 11:07 pm
by Bernd.N
We use one generic recordAdd method for all new records.
It looks up which defaults are needed for the specific tenant, and sets common fields automatically in case they exist in the record, for example
Code: Select all
// Set the create_date/create_user if the column is present in the table, from SERVER (all users have the same time base then...)
if (aColumnNames.indexOf("creation_date") > -1) rRec["creation_date"] = application.getServerTimeStamp() ;

if (aColumnNames.indexOf("creation_user_id") > -1) rRec["creation_user_id"] = scopes.person.currentPersonID ;

Then that method calls a submethod that is specific to the table.
In general, I try to code everything as generic as possible. I do not like when large chunks of code get duplicated somewhere. :wink: