Microsoft has gone barking mad...

jglathe · 2013-10-14

Hi Paul,

I appreciate that you're answering on this. However, I have a few small comments.

pwhite wrote:

I understand your frustration.

Frankly, I'm not sure about that. What went wrong since 2008? Since then, NAV is mostly heading down a path the existing customers (and not only those, IMO) don't want. Now it feels like Microsoft is turning on the afterburner to reach the rock wall faster...

pwhite wrote:

1. Over the last several releases the NAV product has been transformed - from two tier to three - from thick client to web client - from on premise to cloud capable. In doing so we have worked hard to protect the skills, experience, domain expertise and intellectual property in the NAV Partner Community. We recognise the investments you have made in our product. By effecting the technology shift (from NAV 5 through to 2013 R2) we believe we have significantly extended the period over which you can get value from them.

What I hear is "be grateful we didn't simply kill the product".

pwhite wrote:

2. Multi Tenancy is not compulsory. It is however an essential ingredient for some part of our future success. Some existing Partners want to evolve their "traditional" NAV business model towards a more repeatable approach. Cooper Parry (key the Directions Keynote Video) are one example. We're talking to a number of new Partners who want to build net new NAV practices focussed exclusively on the repeatable model. Meantime we continue to support the client specific approach.

Again, the RTM available does suggest otherwise. Either you have more than one bug, or the client specific approach went down the gutter and you didn't tell anyone. And regarding the "new partner" approach: Is this the hint for the old partners to get lost? Anyway, way to go.

with best regards

Jens Glathe

mdPartnerNL · 2013-10-14

vremeni4 wrote:

I think It will take me a few days to create a nice GUI for none technical people to understand how to use it.
In NAV 2013 the process was export company as FBK, import Company, no technical skills needed to do it.

I have seen the howto-videos and as I understand it, you can only copy a company (without objects) if you enable tenants. Which means a NAVobject + NAVdata database. (I hope im wrong!)

kine · 2013-10-17

vremeni4 wrote:

NAV customers do this on everyday basis, they copy, delete rename companies, constantly.
Now they cannot do this any more, only via Powershell.

It is not true and it only shows you never looked into NAV 2013 R2.

Create, delete, rename and copy company could be done directly from Windows Client. And even from the Web Client! It means, it is much easier now than it wasbefore! Just delete, copy, and you are done! No backup, delete, rename, restore and other magics needed!

vremeni4 · 2013-10-17

kine wrote:

It is not true and it only shows you never looked into NAV 2013 R2.

I admit it is a mistake on my part, I did not know there is a new page Companies in RTC client and Web Client.

kine wrote:

Create, delete, rename and copy company could be done directly from Windows Client. And even from the Web Client! It means, it is much easier now than it wasbefore! Just delete, copy, and you are done! No backup, delete, rename, restore and other magics needed!

It what way it is easier, it is the same functionality which was available in Development Environment ?
To do rename, create, delete you do not need a backup.
You only need a backup if you want to move a company from one database into another. E.g. You want to move company from TEST database on another server into LIVE.

By the way as you know NAV 2013 R2 so good could you tell me how to do this?

Thanks.

kine · 2013-10-17

vremeni4 wrote:

kine wrote:

It is not true and it only shows you never looked into NAV 2013 R2.

I admit it is a mistake on my part, I did not know there is a new page Companies in RTC client and Web Client.

kine wrote:

Create, delete, rename and copy company could be done directly from Windows Client. And even from the Web Client! It means, it is much easier now than it wasbefore! Just delete, copy, and you are done! No backup, delete, rename, restore and other magics needed!

It what way it is easier, it is the same functionality which was available in Development Environment ?
To do rename, create, delete you do not need a backup.
You only need a backup if you want to move a company from one database into another. E.g. You want to move company from TEST database on another server into LIVE.

By the way as you know NAV 2013 R2 so good could you tell me how to do this?

Thanks.

All depends on why you need that. If you need to create new company with some initial setup, than you can use the rapidstart to import the data into newly created comany. If you need to make some test company in test database, you can backup live/restore test database and do rename and delete as you want. If you really need to move company from one database to another with big data, you can create SSIS for it or script which will generate needed scripts for you.

There is example I have made in 1,5 hour:

declare @companyname varchar(100) 
declare @targetdb varchar(100) 
declare @targetcompany varchar(100) 
declare @tablename varchar(1000)
declare @columns varchar(8000)
declare @columnname varchar (8000)
declare @targettable varchar (8000)
declare @isidentity int
set @companyname='CRONUS International Ltd_'
set @targetdb='NAV2013R2'
set @targetcompany = 'Test'
DECLARE table_cursor CURSOR for
  select name from sys.all_objects where type='U' and object_id>0 and name like @companyname+'$%'
OPEN table_cursor

FETCH NEXT FROM table_cursor 
INTO @tablename
WHILE @@FETCH_STATUS = 0
BEGIN
    DECLARE column_cursor CURSOR for
    	SELECT COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = @tablename and COLUMN_NAME <> 'timestamp' and DATA_TYPE<>'image'
    select @columns=''
	OPEN column_cursor
    FETCH NEXT from column_cursor
	INTO @columnname
	WHILE @@FETCH_STATUS=0
	BEGIN
		SELECT @columns=@columns+',['+@columnname+']'
		FETCH NEXT from column_cursor
		INTO @columnname
	END
	CLOSE column_cursor;
	DEALLOCATE column_cursor;
	select @columns = SUBSTRING(@columns,2,LEN(@columns)-1)
	select @targettable= @targetdb+'.dbo.['+@targetcompany+SUBSTRING(@tablename,LEN(@companyname)+1,LEN(@tablename)-LEN(@companyname)+1)+']'
	select @isidentity=COUNT(*) FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME =@tablename AND COLUMNPROPERTY(object_id(TABLE_NAME), COLUMN_NAME, 'IsIdentity') = 1
	print 'print '''+@targettable+''''
	IF (@isidentity>0)
	  print 'SET IDENTITY_INSERT '+@targettable+' ON'

	print 'delete from '+@targettable
	print 'insert into '+@targettable+ ' ('+ @columns + ') select '+@columns+' from ['+@tablename+']' 
	IF (@isidentity>0)
	  print 'SET IDENTITY_INSERT '+@targettable+' OFF'

	FETCH NEXT FROM table_cursor 
	INTO @tablename
END 
CLOSE table_cursor;
DEALLOCATE table_cursor;

This script will generate script which will copy the tables from one company and DB (actual db when running the script) to another DB and company (just fill the variables correctly). You can create stored procedure for it, make it better as you wish...

Just one thing - it is not copying BLOBS (images)!!!

Miklos_Hollender · 2013-10-17

Have you guys noticed that it impossible now to copy - paste textboxes in Visual Studio? So you end up setting up font size and stuff like that 100 times manually?

Confirmed bug, regardless of VS version

http://connect.microsoft.com/SQLServer/ ... p2-upgrade

How is it possible that testing got so incredibly bad?

And the reacton on the website is not even "Really sorry guys we suspect many unpaid hours of work it is costing you, we will fix it tomorrow", it will be an "enchancement" in a "future release".

The attitude...

kine · 2013-10-20

Miklos Hollender wrote:

Have you guys noticed that it impossible now to copy - paste textboxes in Visual Studio? So you end up setting up font size and stuff like that 100 times manually?

As in old classic report times... (ok you could copy, but not change font on multiple controls) ;-)

You know, there is no ideal software, there is no ideal developer, there is no ideal tool...

as usual, it is just about "hate and talk" or "do something". There are bugs, you know the rules. And if the app is big, there are BIG :bug: . And if you have worked with something else than NAV, there are much worse and ugly bugs everywhere... But I think that we have tools to make workarounds... it is named "brain"... 8)

Yes, sometime it is hard to find the way around (or it is sometime "impossible" because not enough resources), but than there is the support and I am sure that they are working hard to solve the biggest issues.

I am not happy too because some issues in NAV 2013 R2, but I can live with it, I am sure that they will be resolved before we will go live with our first customer (may be it is because we still do not have Czech version of NAV2013 and it will take some time...)

Miklos_Hollender · 2013-10-21

Kine, the only real problem is being FORCED to used this before it is ready. All they should have done is to simply not discontinue the Classic just keep it around in exactly the same shape and form as in NAV 2009 and then we would just happily use that until the RTC is ready. The kind of parallel use i.e. using RTC Pages but Classic reports in 2009 was a good way to slowly modernize major parts of your system while waiting for the reports to pick up.

Tommy_Schou · 2013-10-21

I would like for MS to just get their damn version list correct. Is that too much to ask ?

Handling multiple language versions is really a bitch when MS decides that ie. table 277 should have version NAVW17.10 in the Danish version but retain the correct version: NAVW17.00 in the W1 version.

This means one more object for us to maintain for every object where MS decides that they need to alter the version list for some weird reason (and Tabl277 is sadly not alone).

If you compare Table 277 in W1 7.10 with DK 7.10 the only difference is the caption. Nothing else. Which means that the version list in the Danish version should be NAVW17.00 and NOT NAVW17.10 which it is now.

I picked that particular table because it is one of the simplest objects in the entire application. 2 fields and 1 function and nothing has been changed between W1 and DK version so the objects are completely identical (excepting CaptionML).

So.. MS. would you please just start with the simplests of things and get that sorted? Thank you!

mdPartnerNL · 2013-10-21

+1 for returning the fbk backup/restore in development. Some problems can only be solved with this and makes development easier.

davmac1 · 2013-10-21

I definitely agree with restoring the backup and restore functions in the developer.
I think Microsoft must not realize how often we use this. :thumbsup:

JasminkaT · 2013-10-22

I don't want to be adding oil on fire, but just wanted to reply to original comment (applying changes from c/side dev. in production area).

Data Loss Protection: Designed in C/SIDE, executed by the server

@ mount time or whenever a client connects
Service account is a db_owner of application database

@ design time
C/SIDE environment: Tools-Options: Prevent data loss from table changes
Enabled by default, not persisted
May prevent changes to table objects
Available in single-tenant and MT mode
Requires running server: c/side cannot check for loss of data anymore!
@ run time
Default behavior
May prevent execution of schema change: tenant becomes unusable
Schema changes can be enforced @ mount time
Only in multi-tenant mode

In other words: you can deploy changes using finsql ONLY (like in 'legacy' mode), without having NST synchronize schema, but then you need to set this parameter to false.
That also means you risk losing data if you are attempting a breaking schema change (removing a field that contains data etc...), which one can assume you're not doing untested at production env.

Parameter can be found in C/Side env. : Tools - Options - Prevent data loss from table changes
Default is Yes and this option is not persisted.

wj_mm · 2013-10-23

"What you are describing is a "known issue" and you mention the workaround. That means there will be a fix for it."

Hello,
probably is this a "known issue" for you, but not for us.
I am searching some hours until I find out that this is a "known issue".

In some cases MS should not all new features testing with "localhost".
This is not the first "known issue" and for us it is not so easy to find out that the problem not we are himself.

Regards
Jürgen

mdPartnerNL · 2013-10-23

tinoruijs wrote:

Today I watched the videos Waldo is refering to on his website in this blog: http://www.waldo.be/2013/09/16/nav2013r2-readiness/

My cautious conclusion is it's best to always create a multi-tenant enviroment. Even if you don't actually need it.
I'm not sure if that's right. :-k

I see great possibilities for multi-tenancy. Seems like a good step.

I agree, always run a script after install.. but is tenant in every license model possible?

Marije_Brummel · 2013-10-23

Just a small update, Microsoft is looking at the FBK issue and will try to come up with an alternative.

http://markbrummel.wordpress.com/2013/1 ... -stewards/

wj_mm · 2013-10-23

Mark Brummel wrote:

"Honestly I cannot recall when I last used this feature other than copying a company within a database. I would be curious to hear real business cases for this feature, especially end-user cases."

Good to hear this,
but probably it can be a good idea to collect informations before features will be deleted.

People where do every day the job with end customers now sometimes more :-)

Marije_Brummel · 2013-10-23

Hey, I don't work for Microsoft, I work freelance and mostly at end user sites.

Looking forward to the business cases. If you post them on my blog like Dave did I have them all in one place.

vremeni4 · 2013-10-23

This is very good news.

Here is my small list of business cases:

1. You need to setup a company but you do not want users to see it or have access to it. You create a company in e.g. TestDB, you complete the setup and you test it. When everything ready you export the company and import it into LIVE environment.
2. There is bug that can only be reproduced with the "correct" data. The SQL backup for some clients can be 20-30GB in size. If client is based in Dubai, Hong Kong, it would take ages to copy it over. Instead you take a backup of the company (zip it), restore it in your development environment and use it for debugging.
3. Testing. Very often clients want to test something in a particular company. The database could be e.g. 200-300 GB, so SQL backup is also around 40 GB. Restoring something like that would take few hours and also quite a lot of disk space. Instead you take a company backup from e.g. LIVEDB and you import it into e.g. TESTdb. There you can do your experiments.
4, Keep a backup for later. Sometimes users want to keep a backup of a company as a reference for later. So they export it as an FBK, and if they need it they can restore it on the Test server.
The SQL backup can be 10 times the size of the size of the individual company backup.
5. FBk can be used to import objects, instead of a FOB file. This is very handy, as you have all objects and company data in one file.
6. Second backup. Call me paranoid, but there is never enough backups. I always create SQL and FBk backup, If something is wrong with SQL backup I still have FBK and another way around.
7. it is easier to extract objects from an FBK then from an SQL backup. If I have an FBK it is straight forward to restore all objects. With SQL backup this is more complicated and needs more time and work.
.....

wj_mm · 2013-10-24

vremeni4 wrote:

This is very good news.

Hey vremeni4,

I see you know your Job =D> .

This is exact was everyone needs.

Kowa · 2013-10-24

Another business case for FBK backup:
8. Users who feel uneasy to open the object designer, because they fear that they might accidentally cause some damage there, can safely use the FBK backup without company data to export just the objects. If I send a request for the current objects of a client's database and afterwards talk to someone on the phone who has little or no field experience in that realm I prefer to use that solution.

vremeni4 · 2013-10-28

Here is a small SQL script (stored procedure) to export company in NAV 2013 R2 and then to import it on a different machine/database.
It is based on the bcp command , and both scripts have to be executed on the SQL server directly.

Create a new folder on the SQL Server e.g. C:\Temp\export\
Make sure that "xp_cmdshell" is enabled on the SQL server.
Run EXEC xp_cmdshell 'whoami.exe' ; to find out the user that will run bcp command.
This user needs to have write permission on the folder C:\Temp\export\ and on the on the database.

Start SQL Studio manager and adjust the script parameters and run it:

--Export script; has to be executed on the SQL server
USE [Demo Database NAV (7-1)]                                          --change this
DECLARE @ExportFolder varchar(250) = 'C:\Temp\export\'         -- Export Company in this folder (make sure folder is empty)
DECLARE @SQLServerInstance VARCHAR(80) = 'SQlServer\nav7'          -- sql server in format SQLServer\Instance
DECLARE @DbName varchar(80) ='Demo Database NAV (7-1)'         -- Export company from this database
DECLARE @CompanyName varchar(80) ='CRONUS International Ltd_'  -- name of the company to export (Name used in SQL not in NAV) 

DECLARE @CmpNameSearch varchar(80)
DECLARE @cmd_bcp varchar(1000)
DECLARE @result int

SET @CmpNameSearch=@CompanyName+'$%'

DECLARE exptable_cur CURSOR FOR
SELECT 'bcp "['+@DbName+'].dbo.['+name+']" out "'+@ExportFolder+
	  SUBSTRING (name, LEN(@CompanyName+'$')+1,LEN(name))+'.txt" -S "'+@SQLServerInstance+'" -T -c'
FROM sys.tables  
WHERE name like @CmpNameSearch
ORDER BY name

OPEN exptable_cur
FETCH NEXT FROM exptable_cur INTO @cmd_bcp
WHILE @@FETCH_STATUS = 0 BEGIN
  PRINT @cmd_bcp
  EXEC @result = xp_cmdshell @cmd_bcp
  IF (@result <> 0) PRINT 'Failure. Table was not exported. -> '+ @cmd_bcp
  FETCH NEXT FROM exptable_cur INTO @cmd_bcp
END 

CLOSE exptable_cur;
DEALLOCATE exptable_cur;

This will export all tables in separate files in the folder C:\Temp\export\.

Now you can use the zip command to compress the folder "export" and transfer it e.g. on another machine.

On another SQL machine Start RTC and create a new company with a name e.g test.
Start SQL Studio manager and adjust the script parameters and run it:

--Import Script; has to be executed on the SQL server
USE [Demo Database NAV (7-1)]    --change this
--run script to enable xp_cmdshell on the SQL server
DECLARE @ImportFromFolder varchar(250) = 'C:\Temp\export\'      -- folder where exported data can be found
DECLARE @SQLServerInstance VARCHAR(80) = 'SQLserver\nav7'       -- sql server in format SQLServer\Instance
DECLARE @DbName varchar(80) ='Demo Database NAV (7-1)'         -- Import company in this database
DECLARE @CompanyName varchar(80) ='test'                         -- name of the new empty company (created in RTC) 

DECLARE @CmpNameSearch varchar(80)
DECLARE @cmd_bcp varchar(1000)
DECLARE @result int

SET @CmpNameSearch=@CompanyName+'$%'

DECLARE table_cur CURSOR FOR
SELECT 'bcp "'+@DbName+'.dbo.'+@CompanyName+'$'+SUBSTRING (name, LEN(@CompanyName)+2,LEN(name))+'" in "'+@ImportFromFolder+
	  SUBSTRING (name, LEN(@CompanyName)+2,LEN(name))+'.txt" -S "'+@SQLServerInstance+'" -T -c -q' as BCP
FROM sys.tables 
WHERE name like @CmpNameSearch
ORDER BY name

OPEN table_cur

FETCH NEXT FROM table_cur INTO @cmd_bcp
WHILE @@FETCH_STATUS = 0 BEGIN
  PRINT @cmd_bcp
  EXEC @result = xp_cmdshell @cmd_bcp
  IF (@result <> 0)
   PRINT 'Failure. Table was not imported. -> '+ @cmd_bcp
  FETCH NEXT FROM table_cur INTO @cmd_bcp
END 

CLOSE table_cur;
DEALLOCATE table_cur;

It is not as good as FBK, but it works.
Potentially this could be done via power shell, too.

$sql = @" 
    USE [Demo Database NAV (7-1)];  
    SELECT 'bcp ""[Demo Database NAV (7-1)].dbo.['+name+']"" out ""C:\Temp\export\""+
 SUBSTRING (name, LEN('CRONUS International Ltd_$')+1,LEN(name))+'.txt"" -S "SQLServer\nav7"" -T -c'
 FROM sys.tables WHERE name like 'CRONUS International Ltd_$%' order by name
"@
Invoke-Sqlcmd -Query $sql -ServerInstance "SQLServer\nav7" | iex

The next step would be to add two buttons (Export Company, Import Company) on the Companies page (357) which would run these stored procedures. This is still work in progress.
I hope this helps until Microsoft release something.

Alex_Chow · 2013-10-28

I think the best solution is to not upgrade your clients to NAV2013 R2 until they release a hotfix for this.

Of course, the hotfix will introduce more bugs and problems.

For new clients, go for it. For existing clients, I'd wait.

paurola · 2013-10-29

vremeni4 wrote:

Here is a small SQL script (stored procedure) to export company in NAV 2013 R2 and then to import it on a different machine/database.
It is based on the bcp command , and both scripts have to be executed on the SQL server directly.
...

Good post. Thanks for sharing, vremeni4.

wj_mm · 2013-10-29

vremeni4 wrote:

Here is a small SQL script (stored procedure) to export company in NAV 2013 R2 and then to import it on a different machine/database.
It is based on the bcp command , and both scripts have to be executed on the SQL server directly.

Hello vremeni4,

thanks for the script, works fine and is a solution for the backup/restore problem.
=D>

Andwian · 2013-10-29

Kowa wrote:

Another business case for FBK backup:
8. Users who feel uneasy to open the object designer, because they fear that they might accidentally cause some damage there, can safely use the FBK backup without company data to export just the objects. If I send a request for the current objects of a client's database and afterwards talk to someone on the phone who has little or no field experience in that realm I prefer to use that solution.

Nice thought! Thanks!

Poltergeist · 2013-12-03

Back to the original problem: I received a new build for NAV 2013R2, and we are now able to change tabledefinitions without having to resort to disabling "Prevent data loss from table changes". The build I received from Microsoft is build 35784, and the KB article is 2907585.

mrQQ · 2014-01-08

Awesome! Thanks Poltergeist.

Vickster69 · 2014-01-29

vremeni4 wrote:

This is very good news.

Here is my small list of business cases:

1. You need to setup a company but you do not want users to see it or have access to it. You create a company in e.g. TestDB, you complete the setup and you test it. When everything ready you export the company and import it into LIVE environment.
2. There is bug that can only be reproduced with the "correct" data. The SQL backup for some clients can be 20-30GB in size. If client is based in Dubai, Hong Kong, it would take ages to copy it over. Instead you take a backup of the company (zip it), restore it in your development environment and use it for debugging.
3. Testing. Very often clients want to test something in a particular company. The database could be e.g. 200-300 GB, so SQL backup is also around 40 GB. Restoring something like that would take few hours and also quite a lot of disk space. Instead you take a company backup from e.g. LIVEDB and you import it into e.g. TESTdb. There you can do your experiments.
4, Keep a backup for later. Sometimes users want to keep a backup of a company as a reference for later. So they export it as an FBK, and if they need it they can restore it on the Test server.
The SQL backup can be 10 times the size of the size of the individual company backup.
5. FBk can be used to import objects, instead of a FOB file. This is very handy, as you have all objects and company data in one file.
6. Second backup. Call me paranoid, but there is never enough backups. I always create SQL and FBk backup, If something is wrong with SQL backup I still have FBK and another way around.
7. it is easier to extract objects from an FBK then from an SQL backup. If I have an FBK it is straight forward to restore all objects. With SQL backup this is more complicated and needs more time and work.
.....

Very well summarised indeed

The lack of fbk option in R2 is driving me crazy - I can't believe that people don't realise how often it is used by anyone who supports Nav! I use it frequently - sometimes daily - on the older versions of Nav, as do a number of my colleagues. I will give that latest script a try, but that means involving our resident SQL expert and he is already overloaded with work, whereas any Nav person can use the fbk quickly and easily.

Please bring back the fbk!!

Vickster69 · 2014-01-29

vremeni4 wrote:

Here is a small SQL script (stored procedure) to export company in NAV 2013 R2 and then to import it on a different machine/database.
It is based on the bcp command , and both scripts have to be executed on the SQL server directly.

(see page 4 for the full script, if required)

I had a quick chat with our SQL expert and he made these comments;

All good as long you have full permission to SQL.
I would not recommend enabling xp_cmdshell as it is a security whole.
So you may find it difficult to use as the person controlling the SQL server may not allow it.

So that rules that out as a suitable alternative for us to use, as a lot of Customers are strict about the SQL server access/usage - which is fair enough.

Back to the drawing board then...to make a big placard to take down to Microsoft's offices - 'BRING BACK THE FBK!'

ara3n · 2014-01-29

they are bringing back the fbk feature on next release. no need to take down to Microsoft's offices.

Howdy, Stranger!

Quick Links

Categories

Microsoft has gone barking mad...

Comments