Earlier today about 5pm EST I talked with Jim, he said he would pass the information along to someone when they became free. I do not know whom got the message but thought I would write this from home since at around 6 I think I got it working. I just do not understand what happened. So I will post my information and maybe someone can tell me.
The IT dept had rebooted the server, said there was a problem. When the server came back two of the folders which each have their own SQL table went into fault mode. They would not execute and they had the red exclaimation on them. When I went into the status it said that column ‘_ndx’ was invalid. At first I went thru and checked all the parameters and they seemed correct. I then attempted to stop and restart the two affected folders. This did not do anything. I did try to make the column requested in the status message, this did not help either. So in a last ditch effort I shut down the entire service and brought it back up. When I did the two tables which were connected to the two folders came up with a message asking which column I wanted to index/key. I choose the columns and now there was no error messages and everything seemed to work ok.
So even though the two tables are relatively small, each contain 99 rows with 10 columns. Do I need to have a column in each table set as an index? Is this why when it rebooted since there was no index set it requested one?
What is the “table name” set to on the groups? Did you set up the table yourself or have FactorySQL create it?
By default, FactorySQL will create a table for each group. It will create an autoincrementing primary key called yourtable_ndx, which is something that it needs. You can change the index in FactorySQL if you need to conform to someone else’s schema.
It sounds like the table existed when you started those groups (after the reboot), but the index column did not. FactorySQL will prompt to add non-existent columns when a group starts if the table already exists.
The two tables in question are progmode1 and timetable. I beleive that when these were set up they were done manually and not thru the FSQL. However when we first started running the project the first time we started the FSQL service it prompted for this same information. When it did so we answer the questions then once the service was up and running we did a save. So shouldnt it have saved this information as well? Or was this information changed somewhat and when we upgraded from 4.1.5 to the most current version it reset these columns so when the service was restarted it prompted again for the information?
We did the upgrade I think about a week or so back and the service had been running fine. The only reason the IT staff did a reboot on the server was some issue and also I think an upgrade security fix for Microsoft SQL. So why did it request this same information?
When it prompted for the index/key column it showed all the headers for the table(s) in question and it let you select which one you wanted to use. So should we add a key/index column header to one of our headers? Will this happen again if we reboot the server?
[quote=“nathan”]What is the “table name” set to on the groups? Did you set up the table yourself or have FactorySQL create it?
By default, FactorySQL will create a table for each group. It will create an autoincrementing primary key called yourtable_ndx, which is something that it needs. You can change the index in FactorySQL if you need to conform to someone else’s schema.
It sounds like the table existed when you started those groups (after the reboot), but the index column did not. FactorySQL will prompt to add non-existent columns when a group starts if the table already exists.[/quote]
If you specified the index column at one time, you shouldn’t have had to do it again. I suppose there could be a problem with the upgrade not transitioning those correctly, but now that you’ve got them defined you should be fine. I did a number of tests with custom column definitions and didn’t run into any problems.
If you have any other problems with them though, please let us know.