I would just like to ask some opinions and experiences.
it seems to me that for LS Retail (and InfoStore for that matter) the most common set up seems to be having the back office running on SQL and the stores running on C/SIDE native database. This of course makes it simpler to install POS stations, but is it the right way to go.
I would prefer to see everything on SQL. The main reason is Code page translation, but there are other reasons that make it easier to manage everything under the same system. Of course if everything is on SQL, then you can optimize all code to be SQL tuned and not have to think about weather this particular code will need to have an IF RECORDLEVELLOCKING THEN ** command.
One particular case that came up recently was where a User entered a new customer name that had a Spanish character. The Search Name field converted it to a different uppercase in SQL than C/SIDE, so the replicator put an invalid character into a code field, and we could not create a backup.
So i guess the question are:
In a mixed mode environment what code page are you using on the SQL database (please mention the NAV country version code you are using and the language on the POS)
What is your preference for the POS stations, Native or SQL? (Assuming SQL Backoffice)
Are there any real issues in running the POS stations on MSDE?
Thanks in advance.
** basically if a client moves to SQL, then I code in SQL, making a solid assumption that they do not ever plan to go back to C/SIDE. So I do not use SETCURRENTKEY unless I need sorting, but that is another discussion.
The last two installation, we went with sql on both as backend and MSDE on store. This is US version 5.0 sp1. SQL on both ends makes the implementation easier and you don’t run into issues that you have mentioned. There are a couple of things that you have to deal with MSDE. First is th 4 gig limit. We have built a End of day process report that the user runs part of end of day process. It deletes unneeded data and through ado truncates the log files. We’ve set the recovery model to simple and have set nightly sql backup and and re index jobs. You have to do some sql tuning on Transaction header, Trans. sales entry, trans. payment entry, etc. We have set all the Store POS computers to reboot at night. This is because Data Director hangs LS Retail just released 2.26 Data director and I haven’t used it yet. Hopefully to actually use CFront new functions for ImportFOB and ExportFOB. This will finally allow object replication. They are also not using GetLastTextError function in they Job Scheduler. I hope in future they get rid of DD and use web service to send and communicate with the store, but I don’t know what the licensing will be like.
The particular client with the codepage issue was on US 5.00 but somehow someone still managed to get a wrong character in there [:P] Shat code page are you using on SQL. Actually we want to move to 5.00 SP1 executables, but want to wait till the new DD is tested (I think it was just released this month right?)
All the rest of the LS Retail or Info-Stores that i am working on are in W1. I have a big project right now, where I would prefer them to move everythign to SQL, but I can see that the 4G limit can be an issue since it means careful management of each system. compared to the Set and Forgetness of Native.
i just want to post you my experience in this field … we are having navision 4 sp1 … installing SQL server on backoffice and native navision on POS … we are replicating with CPlus front … it’s great and very successful … i appreciated Rahed’s setup but i cann’t imagine to install SQL server on each POS if you have too much pos’s like more than 35 POS 's … you can even make a daily backup for native navision … Also we are having too much arabic characters and all are replicated very well …Till now and since 01/01/2008 with 35 pos’s …everything is great …
Thanks Jouhayna Zeidan, all input is very usefull.
Another question, is: Do you normally run the same code base on the POS and the Backoffice?
I am asking for perfromance reasons, i.e. that code optimization will obviously be very different for SQL and Native, and even though perfromance should not be an issue on the POS stations, its still somethign to take into account.