Quantcast
Channel: SCN: Message List - SAP MaxDB
Viewing all 2539 articles
Browse latest View live

MAXDB 7.9 Windows 64 bit community version installation issues

$
0
0

Hello,

 

while trying to install MAXDB 7.9_08_23 Windows 64 bit community version the following problems arised:

 

* When MAXDB 7.6 is still installed, the installer detects an installed sap version and will not proceed.

* windows\syswow64\drivers\etc\services has to be created or the installation will fail.

* there is apparently no 32bit odbc driver included.

* trying to use the 32bit installer (just for odbc) fails.

 

 

The first two problems can of course be easily circumvented (uninstall 7.6, create dummy services file).

Of course I would appreciate when the 32bit odbc driver would find it's way into the 64bit installation.

 

Thanks in advance

 

Peter Willadt


Re: MAXDB Installation error - Some Database application might still be running

$
0
0

Dear Mr. Dakhate,

 

I have almost same problem like that:

 

An error occurred while processing option SAP NetWeaver 7.0 including Enhancement Package 3 > SAP Application Server ABAP > MaxDB > Central System > Central System( Last error reported by the step: System call failed. Error 21 (The device is not ready. ) in execution of system call 'GetVolumePathName' with parameter (E:\), line (203) in file (synxcfsmnt.cpp), stack trace: iaxxejsctl.cpp: 146: EJS_ControllerImpl::executeSbertcript() d:\depot\bas\720_rel\bc_720-2_rel\gen\optu\ntamd64\ins\sapinst\impl\src\ejs\iaxxejsbas.hpp: 461: EJS_Base::dispatchFunctionCall() iaxxejsexp.cpp: 178: EJS_Installer::invokeModuleCall() iaxxbfile.cpp: 966: CIaOsFile::FSMountIterGet_impl() synxcfsmit.cpp: 497: CSyFSMountIteratorImpl::get() synxcfsmnt.cpp: 174: CSyFSMountImpl::CSyFSMountImpl(const CSyPath& E:/) .). You can now:

Choose Retry to repeat the current step.

Choose Log Files to get more information about the error.

Stop the option and continue with it later.

Log files are written to C:\Program Files/sapinst_instdir/NW703/AS-ABAP/ADA/CENTRAL/.

 

What does it mean "the device is not ready?" By the way I'm a windows7 64 bit user

 

 

Hope you can help and get out to this. Badly needed this SAP.

 

Thanks in advance.

 

Robert

Re: MaxDB 7.9 error when importing data from MaxDB 7.6

$
0
0

Hi Werner,
I would be interested in the export command, the import command and the complete message that is logged in the loader.log file for this error. Usually there is mentioned which row in the data file generated the error. If this is the case I would furthermore be interested in this one row (if the data file is readable and not too big to separate this one row).

Did you use the same Loader for export and import?

Best regards,

Steffen

Re: Autolog not backing up log file after specified intervals

$
0
0

Hi Ajay,

 

I don't see any issue here. Autolog seems to be fine, I would rather suggest if you go to log area and can see 0 bytes used then the autolog won't save anything as there is nothing to save every hour, however once you do some transactions then the log area will start having data and if autolog runs it will have something to backup.

 

For now DB backup is running fine which is as your data area is having data which is something that backup can backup. Also just in case check if the log location in file system has permission for backint to create files.

 

Further if you can see the log area is utilized then in 1 hour the file size will be the same area utilized in bytes (expected) until and unless the log area gets full. Instead of having every hour I feel for test systems better to run when log area is full or if it reaches certain limit. This way you know what will be the file size(=log area) and plan accordingly.

 

So.. I feel nothing to worry about as of now.

 

Cheers,

Re: MAXDB 7.9 Windows 64 bit community version installation issues

$
0
0

In the meantime I helped myself (found a 32-bit computer, installed 32-bit version, copied appropriate dlls and regsitry settings).

Not satisfying, bot works.

Peter Willadt

MAXDB 7.9 ODBC SQLPrepare issue

$
0
0

Hello,

 

with MAXDB 7.6 I could use the following command sequences with ODBC

SQLPrepare(SELECT ...)

SQLBindParameter()

SQLExecute()

SQLFetch()

SQLCloseCursor()

and then again

SQLExecute()

SQLFetch()

SQLCloseCursor()

as often as I wanted.

With MAXDB 7.9 (64-bit, Windows) the statement apparently has to be re-initialized completely after SQLCloseCursor().

Am I correct in attributing this behaviour to MAXDB?

Is there a chance that this will change again?

 

Peter Willadt

Re: MAXDB 7.9 ODBC SQLPrepare issue

How to obtain log overwrite mode from DBMCLI?

$
0
0

Hello,

 

in case I have no DB studio at hand and need to use DBMCLI to connect to a MaxDB:

How can I get the status of the log overwrite mode?

 

I'm able to set it via

 

db_execute SET LOG WRITER OFF/ ON

 

 

Regards,

Jens


Re: How to obtain log overwrite mode from DBMCLI?

$
0
0

Hi Jens,

 

Use the below command

 

To enable log overwrite

dbmcli -d <DBNAME> -u SUPERDBA,<pwd> -c db_execute set log auto overwrite on

 

To disable log overwrite

 

dbmcli -d <DBNAME> -u SUPERDBA,<pwd> -c db_execute set log auto overwrite off

 

Regards,

Deepak Kori

Re: How to obtain log overwrite mode from DBMCLI?

$
0
0

Hi Deepak Kori,

 

sorry, I had a copy&paste error and actually wanted to refer to

db_execute set log auto overwrite off/on

 

Stil my original question was:

How can I get the status of the log overwrite mode?

 

Regards,

Jens

Re: How to obtain log overwrite mode from DBMCLI?

$
0
0

Hi Jens,

 

Please use command

 

dbmcli -d <DBNAME> -u SUPERDBA, <pwd> -c db_execute autolog_show

 

Hope this helps.

 

Regards,

Deepak Kori

Re: MAXDB 7.9 ODBC SQLPrepare issue

Re: MaxDB Database Studio on Linux: No application id has been found

$
0
0

Hello Valerio,

I'm aware of not being in a supported environment. But as SLES11 is supported and I'm on OpenSuSE 12.1 I think the difference is not so big. And if packages should be missing, I can install them without problems.

 

Today I started the DatabaseStudio (as user root) and it worked. I changed nothing.

Perhaps I did make something wrong in the past.

 

Never mind, and thank you.

 

 

-----------------------------------------------------------------------------------------

Update:

 

Hello,

also this thread is pretty old, I would like to add something:

The following command has to be executed in the directory in which the DatabaseStudio was installed (as the command from Markus Koerner said: read thread http://scn.sap.com/thread/2002991)

dbus-launch ./dbstudio -vm "/home/user/Downloads/jdk1.5.0_22/bin/java"

And the first time as user root. After that, close the DatabaseStudio and you can then start it as normal user (with Group sdba).

 

Regards, Michael

 

Message was edited by: Michael Teubner

Re: MaxDB 7.9 error when importing data from MaxDB 7.6

$
0
0

Hi,

I used loader 7.6 for export and loader 7.9 for import.

Be we could workaround the issue by modifying the critical column on the 7.6 database.
This is a column with default date format.

 

Regards,

  Werner

Client connection to MaxDB7.9 is very slow

$
0
0

Hello,

 

does any one have an idea why a connection via sqlcli -n hostname -d dbname to the MaxDB (Version 7.9), from remote client is so slow.

I checked that there is no firewall between and traceroute is showing even quick response. It is independent if I use hostname

or IP address. So I guess it is not a network related issue.

Connections to the old environment with MaxDB version 7.6 is fast as usual.
Is there a kind of tracing which I can enable to see what is happening during the first connect?

Any suggestion is welcome.

 

Kind Regards,

  Werner


Re: MaxDB 7.9 error when importing data from MaxDB 7.6

$
0
0

Hi Werner,

well, it is definitely good to know that you were able to workaround the problem! But it doesn't help us to find the problem and to correct it in future versions - so would you mind anyway to send me the export and import command you used + the CREATE TABLE statement and if ever possible the one row in the data file that failed to import.

The Loader uses usually the INTERNAL representation of date and time fields independently how they are defined. So this error is rather strange and would like to have a closer look.

Thx,

Steffen

Re: MaxDB 7.9 error when importing data from MaxDB 7.6

$
0
0


Hi Steffen,

 

the export was done by the following command:
$Sdb_Home/global/programs/bin/loadercli76 -n <hostname> -d <dbname> -u dbadmin,xxxx

 

and the import by use of: $Sdb_Home/private/<dbname>/programs/bin/loadercli -d <dbname> -u superdba,xxxx

 

The problem was a column with default date format, for example:

 

"AEND_DATUM"  Date DEFAULT '19700101'

 

This leads in:

 

// E-25392:    '[SAP AG][LIBSDBOD SO][SAP MaxDB] Datetime field overflow;-3048 POS(309) Invalid date format:ISO'

 

So if the date format was changed to '1970.01.01' it works.

 

Hope this helps for the analyses.

 

Regards,

  Werner

Re: MaxDB 7.9 error when importing data from MaxDB 7.6

$
0
0

Hi Werner,

well, no. Sorry, but I did not mean the call to loadercli but the command that was run. The call does not give any hint how the table was exported and imported. I need the EXPORT and the IMPORT command.

Sorry to bother you again.

Thx,

Steffen

Re: Client connection to MaxDB7.9 is very slow

$
0
0

Hi,


I am not aware of any issue here. Works fine for my test system using 7.9 and 7.6...

You can try MaxDBs 'x_ping' command for further analysis, maybe this helps.

Kind regards,
Thorsten

Re: MaxDB 7.9 error when importing data from MaxDB 7.6

$
0
0

Hi Werner,

ok, got it. Here you go:

The problem is not the data but the definition of the table itself. The Loader did not even create the table upon IMPORT in your case. What's the problem then? The 7.6 Loader creates during EXPORT a table definition that looks similar to this (in the catalog file):

CREATE TABLE

...

<col name> DATE DEFAULT '19700101'

...

 

Here the explicit default value for the date column is represented in INTERNAL format. And if you would have used the 7.6 Loader to IMPORT, no error would have happened. It can deal with this format in definitions. But you used the 7.9 Loader to import the table. And this one expects an explicit default value for date in table definitions in ISO format (1970-01-01) because it creates those upon EXPORT. So here already the table creation fails.

If you would have used the 7.9 Loader for EXPORT and IMPORT this error would not have happened, too.

Regards,

Steffen

Viewing all 2539 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>