Object Import Issues

MP_NAV

Nav 3.7 - Native DB

I have attempted to import 8 objects into the database. One of the objects is the Sales Invoice Line table which is re-designed during the import process. Once the import has completed and I receive the verification informing that 7 objects have been replaced and 1 has been created I have checked the date/time stamp in the object designer, gone and actually looked at the forms that were imported and everything is as expected.

Upon connecting to the DB (using the service) from a client pc, the objects have returned to their previous state.

Has anyone experienced this before?

I have loaded objects recently without issue on this db, but for some reason this set seems to be rolling back.

Thank you for any help you can provide.

David_Singleton

I think you are connecting to the wrong database.

MP_NAV

I wish it were that simple. I only have one database on the network and I am certain that it is this one... any other thoughts? thanks for that idea though...

Savatage

why not import the objects right from the clients pc - then it will have to be the correct database

MP_NAV

I have imported while connected via the Service, which ensures that I am connected to the production database.

Is it possible that Commit Cache could be causing issues due to the redesigning of the Sales Invoice Line table? My understanding of the exact use of the Commit Cache is very shaky so at this point I am grasping...

Savatage

I never personally heard of this - when it says 7 objects replaced then that's exactly what it did.

I guess you have to go back to the basics and make sure your importing the new "Changed" objects first of all and that it's the proper database 2nd of all.

is the client - loging out of navision & then logging back in after the changes are complete? else they won't see the changes.

if all else fails restart everything server & client pc 8-[

Savatage

MP_NAV wrote:

I wish it were that simple. I only have one database on the network and I am certain that it is this one... any other thoughts? thanks for that idea though...

just curious if you have 1 database then where did you makes these changes? If you made the changes in the live database then no importing would be needed. Unless you edited them in a txt file.

MP_NAV wrote:

I have imported while connected via the Service, which ensures that I am connected to the production database.

:-k

kriki

Are you sure that the client was completely disconnected (File=>Database=>Close) and reconnected after the upgrade?
If you were still connected it is possible the client object cache still had the old objects in the cache.

David_Singleton

I think you are connecting to the wrong database.

kriki

David Singleton wrote:

I think you are connecting to the wrong database.

That is my second idea.
How to test it: change something in the DB on a client and it should have also changed on the other client. If it hasn't changed, it is very clear it is a different DB.

diptish.naskar

I have imported while connected via the Service, which ensures that I am connected to the production database.

Is it possible that Commit Cache could be causing issues due to the redesigning of the Sales Invoice Line table? My understanding of the exact use of the Commit Cache is very shaky so at this point I am grasping...

Well...you can go and try this..

1. Import the fob from the client database and do check on which database you are login into. Ensure its the database that you want to update.

2. Stop the Navision Service from the SERVER, before doing this activity ensure that all the users are logged out of the database

3. Restart the service and open the client (of course with the correct db) and check whether the update had taken place.

Do let us know..how did it went.

DenSter

Commit cache is for data, not objects. If you imported objects into a database, and you can't see them from a client session, then my first (and only) guess is that the objects were imported into the wrong database.

David_Singleton

Hey Daniel, what we need to do is work out a way that we can give both the correct answer, AND the answer that the poster wants to hear all in one reply.

DenSter

Yeah that would be a cool trick wouldn't it

I'm sure it is a misunderstanding though, this is very puzzling to me. There's really only one explanation that I can think of and that is that the objects were imported into a Cronus database, not the published database. That or someone else imported the original objects back in. :-k

MP_NAV

I hear ya guys! As I said though, this is the second attempt that has failed with the same results. Importing the objects while connected to the DB via the Windows Service DOES make me feel confident that I am importing into the correct database though.

FYI- I would ALWAYS prefer the correct answer as opposed to the one I may think I am looking for.

My next move is to import each object individually as maybe 8 objects is just too much for NAV lol.

I will update this posting once I have attempted once again.

DenSter

It has to be the connection, I am positive of it. I regularly import thousands of objects, 8 is no problem.

Have you verified that on the database information form, on the Connection tab, the Server is checked, and that the servername is filled in? Try inserting a dummy Item or something, and see if you can see that Item with the other client. If you can't, then for sure you are looking at a different database.

Maybe it's a service with the same name running on another computer. Instead of using the servername, try using the server's IP address instead. Pull your network cable out and see if you can still open NAV.

Savatage

another quick check would to create some bogus report #50099 or use a # that the client doesn't have. no replication would be needed and it should import without problems.

In the Import Worksheet are you selecting "ALL" and clicking "Replace All"

MP_NAV

Good thought on the bogus object, may need to try that.

Yes I am sure I selected Replace All, as when the import has completed both times, I have received the verification that 7 were Replaced and 1 was created. As I mentioned, I have gone to the modified forms and seen that the changes have occured, they just do not stick once I close the db out.

I've checked to ensure I have enough available room in the db for the redesigning of the tables, the cache is maxed at 1 gig, no clients connected, tried connected via the service and connected direct to the db file with my dbms set to 1 gig (while connected direct)...

Scratching my head... ](*,)

David_Singleton

MP_NAV wrote:

I hear ya guys! As I said though, this is the second attempt that has failed with the same results. Importing the objects while connected to the DB via the Windows Service DOES make me feel confident that I am importing into the correct database though.

FYI- I would ALWAYS prefer the correct answer as opposed to the one I may think I am looking for.

My next move is to import each object individually as maybe 8 objects is just too much for NAV lol.

I will update this posting once I have attempted once again.

OK, well if you want the correct answer, then

"You are connected to the wrong database"


BTW what does "connected to the DB via the Windows Service" mean, and why would it confirm that you have the correct database?

MP_NAV

Thought being that if I only have 1 Database Server Service installed, and I connect via the SERVER, as opposed to directly to the db file, then I can only possibly be connected to the database that the service is pointed towards.

David_Singleton

MP_NAV wrote:

Thought being that if I only have 1 Database Server Service installed, and I connect via the SERVER, as opposed to directly to the db file, then I can only possibly be connected to the database that the service is pointed towards.

I am not sure what you want to hear. Clearly you are connecting to one database locally, and then a different database via the server. Why do you feel that a local connection, AND then the server should access the same database.

You have a multitude of options given here to test if its the same database. Why, when there is a 99.9% chance that you are connected to the wrong database, won't you test that one issue.

This is going beyond silly at this point. :evil:

MP_NAV

I do apprecieate the ideas, and I AM going to test using ALL suggestions given. Skeptical or not I am still going to follow each potential solution to the end.

David_Singleton

MP_NAV wrote:

I do apprecieate the ideas, and I AM going to test using ALL suggestions given. Skeptical or not I am still going to follow each potential solution to the end.

Excellent just be aware, that everything you have posted to this point indicates you are connecting to the wrong database. So resolve that issue fist, THEN worry about importing the objects.

MP_NAV

I realize the original posting occured quite a while in the past, however I did resolve the issue and thought that I should post the results as this thread has been viewed a few times.

As it turns out, I was connected to the correct database. This issue was related to the Commit Cache. The Cache was being filled and the object changes were not being written to the database. Server Harddrive space was increased and the page file was also increased. After the last import a message appeared that the Commit Cache was temporarily filled and after allowing NAV the time it apparently needed the changes were written the the DB.

Monitoring the page file usage during the import/table redesigning indicated that we were utilizing almost all of the OS page file.

Thanks to all for the suggestions.