I would like to take the touchscreen files from a Micros 4.x to a 3700 3.x system. The straight transfer of the OpsDisplaySys.cfg file doesn't work. I get errors when the Server POS ops loads up. Is there a way to transfer this file or individual screens over to the older system?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Move Micros Touchscreen Files
- Thread starter pkuck
- Start date
OpsDisplaySys.cfg just holds template definitions, not the full touchscreens. The screen definitions are held in two tables in the database - micros.ts_scrn_def holds the info about the overall screen layout and micros.ts_key_def holds the details for all the items you put on the screen with touchscreen designer.
There's not really an easy way to move touchscreens between databases. I've used SQL to export/import screens before, but unless the sequence numbers for your SLU's, menu items, tenders and basically anything else user defined are the same you're going to have problems.
There's not really an easy way to move touchscreens between databases. I've used SQL to export/import screens before, but unless the sequence numbers for your SLU's, menu items, tenders and basically anything else user defined are the same you're going to have problems.
- Thread starter
- #3
The layout would import as long as the screen sequence or number doesn't already exist in the destination database. Whenever I did this it was on databases that were almost identical so I didn't have to worry about the tenders, slu's, etc. I don't think these table enforce foreign key constraints so the buttons will probably import even if they don't match, but who knows what, if anything, they'll be linked to.
This has to be done in dbidql. You'll have to write queries to get the info you need from both tables, then use the export feature to dump it into flat files. Import these into temporary tables in the destination database using dbisql's import feature, then you'll have to write queries to insert the data from the temp tables into the live tables.
Needless to say, if you're not comfortable with SQL you should play around on a test system for a while before trying somthing like this.
This has to be done in dbidql. You'll have to write queries to get the info you need from both tables, then use the export feature to dump it into flat files. Import these into temporary tables in the destination database using dbisql's import feature, then you'll have to write queries to insert the data from the temp tables into the live tables.
Needless to say, if you're not comfortable with SQL you should play around on a test system for a while before trying somthing like this.
- Status